New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to Tornado 6 #21469
Upgrade to Tornado 6 #21469
Conversation
Hello @zulip/server-dependencies members, this pull request was labeled with the "area: dependencies" label, so you may want to check it out! |
All the changes here lgtm aside from settling some plan for telling whether a Tornado process is close to being overloaded. |
This does seem to work in production and development, but still needs test suite wrangling. |
95a4d84
to
fdfce23
Compare
Hmm. This breaks heartbeat events somehow. |
Fixed that bug, I think, and added a safeguard to prevent the kind of accidental creation of extra event loops that triggered it. |
3a57374
to
b41e2cd
Compare
1b30aaa
to
f4b4ac9
Compare
3c04322
to
b7cac58
Compare
Test-deploying this updated version on chat.zulip.org. |
(Updated the asgiref patch to the commit merged upstream in django/asgiref#320. No relevant differences; it was just rebased on top of some test suite changes.) |
30fae99
to
eebeba5
Compare
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We previously forked tornado.autoreload to work around a problem where it would crash if you introduce a syntax error and not recover if you fix it (tornadoweb/tornado#2398). A much more maintainable workaround for that issue, at least in current Tornado, is to use tornado.autoreload as the main module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
IOLoop.set_blocking_log_threshold and IOLoop.handle_callback_exception are removed in Tornado 6. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
According to the documentation: “Pika does not have any notion of threading in the code. If you want to use Pika with threading, make sure you have a Pika connection per thread, created in that thread. It is not safe to share one Pika connection across threads, with one exception: you may call the connection method add_callback_threadsafe from another thread to schedule a callback within an active pika connection.” https://pika.readthedocs.io/en/stable/faq.html This also means that synchronous Django code running in Tornado will use its own synchronous SimpleQueueClient rather than sharing the asynchronous TornadoQueueClient, which is unfortunate but necessary as they’re about to be on different threads. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Fixes zulip#8913. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Thank for all of this cleanup, @andersk! Excited to have removed this crusty old version pin. |
Commit 6fd1a55 (zulip#21469) introduced an await point where get_events_backend calls fetch_events in order to switch threads. This opened the possibility that, in the window between the connect_handler call in fetch_events and the old location of this assignment in get_events_backend, an event could arrive, causing ClientDescriptor.add_event to crash on missing handler._request. Fix this by assigning handler._request earlier. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 6fd1a55 (#21469) introduced an await point where get_events_backend calls fetch_events in order to switch threads. This opened the possibility that, in the window between the connect_handler call in fetch_events and the old location of this assignment in get_events_backend, an event could arrive, causing ClientDescriptor.add_event to crash on missing handler._request. Fix this by assigning handler._request earlier. Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 6fd1a55 (zulip#21469) introduced an await point where get_events_backend calls fetch_events in order to switch threads. This opened the possibility that, in the window between the connect_handler call in fetch_events and the old location of this assignment in get_events_backend, an event could arrive, causing ClientDescriptor.add_event to crash on missing handler._request. Fix this by assigning handler._request earlier. Signed-off-by: Anders Kaseorg <anders@zulip.com> (cherry picked from commit e112b61)
Commit 6fd1a55 (#21469) introduced an await point where get_events_backend calls fetch_events in order to switch threads. This opened the possibility that, in the window between the connect_handler call in fetch_events and the old location of this assignment in get_events_backend, an event could arrive, causing ClientDescriptor.add_event to crash on missing handler._request. Fix this by assigning handler._request earlier. Signed-off-by: Anders Kaseorg <anders@zulip.com> (cherry picked from commit e112b61)
This removes the
instrument_tornado_ioloop
logging hack that cannot be ported past Tornado 4. We should replace it with a simpler metric, such as the fraction of time we spend blocked onbasic_consume
waiting for a message, or just the average length of the queues.