Hope I’m not wasting anyone’s time again… …I’m just doing a lot of syncing with remote colleagues during this strange period, and since the release of 1.4.0 (yay again!), I’m having great fun watching the sync queue progress. It’s an extremely satisfying experience…
So, with the caveat that I might be entirely wrong, I think I’ve just seen something which causes syncs to hang for a while: a 2.5GB file was being pulled from a remote colleague - but then it seemed to hang for quite a while - probably a good ten minutes. During this time, the queue didn’t appear to progress at all.
The blockage then suddenly lifted, and loads of other files in the queue started flowing in from a NAS on the local network.
The lifting of the blockage was accompanied by the following log entries:
2020-03-26 08:43:54 Connection to KF4COM3-*******-*******-*******-*******-*******-*******-******* at 192.168.181.27:64613-82.xx.yy.zzz:65450/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: writing message: write tcp 192.168.181.27:64613->82.xx.yy.zzz:65450: write: broken pipe 2020-03-26 08:44:22 Puller (folder "Updates - *****" (pmf4l-*****), item "<file path here>"): pull: connection closed
If I understand correctly, pulls are fulfilled by the peer to respond first - which makes sense. But is there any provision for a peer to respond, but then hang whilst fulfilling the pull request, without blocking the rest of the queue until it times out many minutes later?
I’m guessing this might be more of an issue since the move to large blocks.
Thanks, and feel free to dismiss me if it’s already being handled!