[JGIT PATCH 1/2] Fix deadlock in native git protocol client for upload-pack

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 10, 2009, 22:48 UTC
Message-ID: <1241995685-13260-1-git-send-email-spearce@spearce.org>

The upload-pack protocol states that for every flush packet (aka "0000") sent by the client, we get exactly one NAK or ACK line back. However, if multi_ack is enabled, we may get multiple "ACK %s continue" lines before the ACK/NAK is sent by the upload-pack server.

Unfortunately, JGit was counting an "ACK %s continue" as a response to a flush packet, causing the client side to stop reading from the server too early. This left a lot of "ACK %s continue" lines in the server output buffer, eventually causing the server to stop and wait for the output buffer to drain. However, the client would also get stuck after sending too many "have %s" lines, eventually deadlocking the entire client-server pair.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 .../jgit/transport/BasePackFetchConnection.java    |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
index f07cc4e..eaa94bd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
@@ -359,15 +359,15 @@ private void negotiate(final ProgressMonitor monitor) throws IOException,
 				continue;
 			}
 
-			while (resultsPending > 0) {
+			for (;;) {
 				final PacketLineIn.AckNackResult anr;
 
 				anr = pckIn.readACK(ackId);
-				resultsPending--;
 				if (anr == PacketLineIn.AckNackResult.NAK) {
 					// More have lines are necessary to compute the
 					// pack on the remote side. Keep doing that.
 					//
+					resultsPending--;
 					break;
 				}

-- 
1.6.3.48.g99c76