Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorShawn O. Pearce2011-03-15 01:18:49 +0000
committerShawn O. Pearce2011-04-21 23:14:31 +0000
commitb209671d04611ad9821cc538c46651452dea0ace (patch)
treed9f59569c5546b60ac196f373446b05d1220e528 /org.eclipse.jgit.packaging/org.eclipse.jgit.feature
parent33e65ec6911795cf2816af1f64b5699dd898d59f (diff)
downloadjgit-b209671d04611ad9821cc538c46651452dea0ace.tar.gz
jgit-b209671d04611ad9821cc538c46651452dea0ace.tar.xz
jgit-b209671d04611ad9821cc538c46651452dea0ace.zip
Implement the no-done capability
Smart HTTP clients may request both multi_ack_detailed and no-done in the same request to prevent the client from needing to send a "done" line to the server in response to a server's "ACK %s ready". For smart HTTP, this can save 1 full HTTP RPC in the fetch exchange, improving overall latency when incrementally updating a client that has not diverged very far from the remote repository. Unfortuantely this capability cannot be enabled for the traditional bi-directional connections. multi_ack_detailed has the client sending more "have" lines at the same time that the server is creating the "ACK %s ready" and writing out the PACK stream, resulting in some race conditions and/or deadlock, depending on how the pipe buffers are implemented. For very small updates, a server might actually be able to send "ACK %s ready", then the PACK, and disconnect before the client even finishes sending its first batch of "have" lines. This may cause the client to fail with a broken pipe exception. To avoid all of these potential problems, "no-done" is restricted only to the smart HTTP variant of the protocol. Change-Id: Ie0d0a39320202bc096fec2e97cb58e9efd061b2d Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Diffstat (limited to 'org.eclipse.jgit.packaging/org.eclipse.jgit.feature')
0 files changed, 0 insertions, 0 deletions

Back to the top