Dima Zavin <dima@xxxxxxxxxxx> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> index 71acda1..80c154b 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> @@ -351,7 +351,7 @@ private void negotiate() throws IOException {
> if (line.length() == 0) {
> if (commonBase.isEmpty() || multiAck)
> pckOut.writeString("NAK\n");
> -
> + pckOut.flush();
> } else if (line.startsWith("have ") && line.length() == 45) {
> final ObjectId id = ObjectId.fromString(line.substring(5));
> if (matchHave(id)) {
Applied, but with this more verbose commit message:
--8<--
upload-pack: Force an fd flush after receiving flush pkt from client
The client is blocked waiting for an ACK or NAK line from the server.
If we don't call flush() here there is a very good chance the
ACK/NAK is stuck in our stream buffer within the JRE, and doesn't
make it into the kernel's TCP buffer. This causes the server to
wait for more have lines, and the client to wait for the ACK/NAK,
and the entire thing just deadlocks.
We flush anytime we see a pkt-line flush command, as there may be
buffered ACK lines from prior evaulations that need to be sent to
the waiting client.
Signed-off-by: Dima Zavin <dima@xxxxxxxxxxx>
Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx>
---
--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
