As of commit 5eaac7bfba (#18),
zulip.Client is not thread-safe and especially not fork-safe due to
connections held open by requests.Session.
Delay construction of the Client until after forking off
zulip_to_zephyr. Replace the fork for each message sent by
zephyr_to_zulip with a threaded queue worker.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The mirror has some chance of running on Python 3 now, once the
python-zephyr patch is rebased on 0.2.1, though it’s untested.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This reduces the number of retries that might spam APIs.
There is some complexity here which is left un-managed -- for
instance, maybe_restart_mirroring_script does a number of restart
attempts, and then fails, but will be retried every 15s by the
surrounding `process_loop`. Previously, it would merely have looped
forever inside maybe_restart_mirroring_script.
Three loops are intentionally left as infinite `while True` loops,
that merely cap their backoff at the default 90s. Their callers do
not expect, or have any way to handle more gracefully, a failure of
the expected-infinite-loop in `process_loop` or `zulip_to_zephyr`.
They maintain their previous behavior of retrying forever, albeit more
slowly.
In principle these should be fixed properly, but the zephyr code is
difficult to test except in a production setting and is unlikely to be
heavily developed in future.
These were quite messy code, and now that almost nobody is running
their own zephyr mirroring script (vs. using webathena), making the
zephyr mirroring script deployable outside the package isn't super
valuable.
In order to keep all three packages (zulip, zulip_bots,
zulip_botserver) in the same repo, all package files must now
be nested one level deeper.
For instance, python-zulip-api/zulip_bots/zulip_bots/bots/, instead
of python-zulip-api/zulip_bots/bots/.
2017-07-18 02:20:32 -02:30
Renamed from integrations/zephyr/zephyr_mirror_backend.py (Browse further)
