| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
has become too long to be useful, and I find I don't need it anymore
to keep things straight
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Only 2 threads are needed, one running, and one waiting to push something
new. Any more is redundant and wasteful.
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| | |
compatibility with previous versions of git-annex, which will refuse to accept any XMPP pushes from this version.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
debian/changelog
doc/design/assistant/more_cloud_providers.mdwn
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Fixed handling of case when file does not exist to work like it did before,
and avoid an excess stat call.
|
| |\ |
|
|\ \ \
| | |/
| |/| |
|
|\ \ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | | |
This fixes a bug where a direct mode sync fails to delete broken symlinks.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This will avoid losing any messages received from 1 client when a push
involving another client is running.
Additionally, the handling of push initiation is improved,
it's no longer allowed to run multiples of the same type of push to
the same client.
Still stalls sometimes :(
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ |
|
|/ |
|
| |
|