diff options
author | 2013-05-21 00:59:38 -0400 | |
---|---|---|
committer | 2013-05-21 00:59:38 -0400 | |
commit | d78527c2f7b902827fdf204f536199963c78419c (patch) | |
tree | 1cb9b1837b3e6a144370d0895414a3de0098cdd4 /Assistant/Types/ThreadName.hs | |
parent | c65c4fc5202c9f94ad5ecd4d6d6a138ad923232d (diff) |
XMPP: Be better at responding to CanPush messages when busy with something else.
Observed: With 2 xmpp clients, one would sometimes stop responding
to CanPush messages. Often it was in the middle of a receive-pack
of its own (or was waiting for a failed one to time out).
Now these are always immediately responded to, which is fine; the point
of CanPush is to find out if there's another client out there that's
interested in our push.
Also, in queueNetPushMessage, queue push initiation messages when
we're already running the side of the push they would initiate.
Before, these messages were sent into the netMessagesPush channel,
which was wrong. The xmpp send-pack and receive-pack code discarded
such messages.
This still doesn't make XMPP push 100% robust. In testing, I am seeing
it sometimes try to run two send-packs, or two receive-packs at once
to the same client (probably because the client sent two requests).
Also, I'm seeing rather a lot of cases where it stalls out until it
runs into the 120 second timeout and cancels a push.
And finally, there seems to be a bug in runPush. I have logs that
show it running its setup action, but never its cleanup action.
How is this possible given its use of E.bracket? Either some exception
is finding its way through, or the action somehow stalls forever.
When this happens, one of the 2 clients stops syncing.
Diffstat (limited to 'Assistant/Types/ThreadName.hs')
0 files changed, 0 insertions, 0 deletions