mirror of
https://github.com/zulip/zulip.git
synced 2025-10-30 11:33:51 +00:00
ea6934c26d
Zulip has had a small use of WebSockets (specifically, for the code path of sending messages, via the webapp only) since ~2013. We originally added this use of WebSockets in the hope that the latency benefits of doing so would allow us to avoid implementing a markdown local echo; they were not. Further, HTTP/2 may have eliminated the latency difference we hoped to exploit by using WebSockets in any case. While we’d originally imagined using WebSockets for other endpoints, there was never a good justification for moving more components to the WebSockets system. This WebSockets code path had a lot of downsides/complexity, including: * The messy hack involving constructing an emulated request object to hook into doing Django requests. * The `message_senders` queue processor system, which increases RAM needs and must be provisioned independently from the rest of the server). * A duplicate check_send_receive_time Nagios test specific to WebSockets. * The requirement for users to have their firewalls/NATs allow WebSocket connections, and a setting to disable them for networks where WebSockets don’t work. * Dependencies on the SockJS family of libraries, which has at times been poorly maintained, and periodically throws random JavaScript exceptions in our production environments without a deep enough traceback to effectively investigate. * A total of about 1600 lines of our code related to the feature. * Increased load on the Tornado system, especially around a Zulip server restart, and especially for large installations like zulipchat.com, resulting in extra delay before messages can be sent again. As detailed in https://github.com/zulip/zulip/pull/12862#issuecomment-536152397, it appears that removing WebSockets moderately increases the time it takes for the `send_message` API query to return from the server, but does not significantly change the time between when a message is sent and when it is received by clients. We don’t understand the reason for that change (suggesting the possibility of a measurement error), and even if it is a real change, we consider that potential small latency regression to be acceptable. If we later want WebSockets, we’ll likely want to just use Django Channels. Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
31 lines
1.1 KiB
Python
31 lines
1.1 KiB
Python
import atexit
|
|
|
|
import tornado.web
|
|
from django.conf import settings
|
|
from zerver.tornado import autoreload
|
|
|
|
from zerver.lib.queue import get_queue_client
|
|
from zerver.tornado.handlers import AsyncDjangoHandler
|
|
|
|
def setup_tornado_rabbitmq() -> None: # nocoverage
|
|
# When tornado is shut down, disconnect cleanly from rabbitmq
|
|
if settings.USING_RABBITMQ:
|
|
queue_client = get_queue_client()
|
|
atexit.register(lambda: queue_client.close())
|
|
autoreload.add_reload_hook(lambda: queue_client.close())
|
|
|
|
def create_tornado_application(port: int) -> tornado.web.Application:
|
|
urls = (
|
|
r"/notify_tornado",
|
|
r"/json/events",
|
|
r"/api/v1/events",
|
|
r"/api/v1/events/internal",
|
|
)
|
|
|
|
# Application is an instance of Django's standard wsgi handler.
|
|
return tornado.web.Application([(url, AsyncDjangoHandler) for url in urls],
|
|
debug=settings.DEBUG,
|
|
autoreload=False,
|
|
# Disable Tornado's own request logging, since we have our own
|
|
log_function=lambda x: None)
|