git-upload-pack gets killed for large changes

[Arvid E.P.]

when uploading a large change:

debug1: channel 0: free: client-session, nchannels 1

debug1: fd 0 clearing O_NONBLOCK

debug1: fd 1 clearing O_NONBLOCK

Connection to codereview.our.domain closed by remote host.

Transferred: sent 13202448, received 6272 bytes, in 64.7 seconds

Bytes per second: sent 204056.1, received 96.9

debug1: Exit status -1

fatal: The remote end hung up unexpectedly

fatal: recursion detected in die handler

in the ssh log:

[2013-02-21 10:05:00,414 +0000] fae750fb aep  a/1000140 'git-receive-pack '\''/stuff/bla.git'\''' 0ms 64627ms killed

and of course as a result, after some seconds, in the error log:

org.apache.mina.core.write.WriteToClosedSessionException

at org.apache.mina.core.polling.AbstractPollingIoProcessor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:625)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:586)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:547)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$800(AbstractPollingIoProcessor.java:67)

at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1119)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

at java.lang.Thread.run(Thread.java:679)

any idea what is happening here? the (binary)change is big, but i see no setting for timeouts in the gerrit config, so i'm not sure if this is actually a timout issue or something else.

[Saša Živkov]

On Thu, Feb 21, 2013 at 11:17 AM, Arvid E.P. <darkwin...@gmail.com> wrote:

when uploading a large change:

debug1: channel 0: free: client-session, nchannels 1

debug1: fd 0 clearing O_NONBLOCK

debug1: fd 1 clearing O_NONBLOCK

Connection to codereview.our.domain closed by remote host.

Transferred: sent 13202448, received 6272 bytes, in 64.7 seconds

Bytes per second: sent 204056.1, received 96.9

debug1: Exit status -1

fatal: The remote end hung up unexpectedly

fatal: recursion detected in die handler

in the ssh log:

[2013-02-21 10:05:00,414 +0000] fae750fb aep  a/1000140 'git-receive-pack '\''/stuff/bla.git'\''' 0ms 64627ms killed

If I remember well the "killed" at the end of an ssh_log entry means that the client closed

the connection.

and of course as a result, after some seconds, in the error log:

org.apache.mina.core.write.WriteToClosedSessionException

at org.apache.mina.core.polling.AbstractPollingIoProcessor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:625)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:586)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:547)

at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$800(AbstractPollingIoProcessor.java:67)

at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1119)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

at java.lang.Thread.run(Thread.java:679)

any idea what is happening here? the (binary)change is big, but i see no setting for timeouts in the gerrit config, so i'm not sure if this is actually a timout issue or something else.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Arvid E.P.]

Yeah. Seen that in another thread. The client log appears to tell that the server is doing it. Any more debugging ideas?

[Saša Živkov]

On Thu, Feb 21, 2013 at 1:18 PM, Arvid E.P. <darkwin...@gmail.com> wrote:

Yeah. Seen that in another thread. The client log appears to tell that the server is doing it. Any more debugging ideas?

In such cases you can use a protocol sniffing tool (tcpdump, wireshark) on BOTH sides at the same time

and check who is closing the connection.

It may even happen that there is a component in the middle (a proxy?) which is responsible for closing the connection.