Are you sure you looked at the right version of JGit? In the current
version its 467 lines, and according to this trace, its at least 458
lines in the version that you are running. -)
> [2011-02-23 00:04:21,754] ERROR
> com.google.gerrit.server.git.PushReplication : Cannot replicate to
> gerrit2@cnbjlnx001:/srv/gerrit2/git/platform/vendor/semc/packages/apps/
> metadata-cleanup.git
> org.eclipse.jgit.errors.TransportException: gerrit2@cnbjlnx001:/srv/
> gerrit2/git/platform/vendor/semc/packages/apps/metadata-cleanup.git:
> channel is not opened.
Thanks JSch:
> Caused by: com.jcraft.jsch.JSchException: channel is not opened.
> at com.jcraft.jsch.Channel.connect(Channel.java:188)
> at org.eclipse.jgit.transport.TransportGitSsh
> $JschConnection.connect(TransportGitSsh.java:224)
JSch is even worse software than Gerrit itself. Probably the only
thing that will fix this is to switch to JGit to use the MINA SSHD
client, which seems to have fewer bugs, and better programmers behind
it.
More recent versions of JGit (0.11.1, and maybe some earlier builds
than that) support setting the GIT_SSH environment variable. If set it
will use that command to open the SSH connection, instead of the JSch
library. You might try setting GIT_SSH=ssh in your environment when
you launch Gerrit, assuming you are able to upgrade your Gerrit WAR to
use that newer JGit library.
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
None. I haven't upgraded Gerrit to use this newer version of JGit yet.
It *might* be as simple as replacing the JGit JARs with the latest
from the JGit project. But I cannot remember if there were API changes
or not, if there are API changes in JGit then Gerrit might need a few
(minor) source code edits to run on the latest JARs.
There are API changes in the HEAD, I tried it. But I
believe it works to update it to the stable-0.11 version.
-Martin
I think its a timing bug in JSch. The JSch authors think the
constructs they are using are thread-safe in Java. They aren't. There
are a number of race conditions between different threads for each SSH
connection, and sometimes things don't work like the authors think
they should.
I've looked through the code and given up on trying to fix it. Its
just too damn ugly. A for loop with explicit sleeps and no locking is
not the right way to share data between two threads in Java. Or any
programming language. It might work on a single CPU system with only
cooperative threading, but nobody does that anymore (and hasn't for
years!).