Ouch!
> I think it has to do with getHostName in the code.... Check out this
> example:
>
> time ssh -p 29418 xx.xx.xx.xx gerrit show-connections
> real 0m5.532s
>
> time ssh -p 29418 xx.xx.xx.xx gerrit show-connections -n
> real 0m0.494s
Hmm, yes, that does seem to be suggesting that looking up hostnames
through your DNS server is taking 5s. Or at least that's true coming
from the JVM you are running. :-)
Perhaps your primary DNS server in /etc/resolv.conf isn't responding?
So the JVM is looking up on that server first, waiting 5s for it to
timeout with no response, then going to the next fallback server and
finally getting an answer. But maybe other programs on your system
are searching them concurrently, or are starting a query on the
secondary server after a much lower timeout waiting for the primary,
so you aren't really noticing this issue with other applications.
Just a shot in the dark, but I'm reasonably certain the JVM does its
own DNS client these days.
> Anyone have any suggestions for a quick fix? Maybe an option in the
> configuration?
If re-ordering your resolv.conf doesn't work, you can try increasing
the number of threads in the replication.config remote block for the
relevant remote. Permitting more concurrent connections will help you
to do those DNS lookups in parallel, rather than serial, so its 5 *
100 / threads rather than 5 * 100 seconds. :-\
Actually this old Sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=5092063
suggests that the 5s latency can occur when there is no reverse DNS
entry configured for a given IP address. Its possible that the JSch
client code is looking up the hostname, discarding it and getting the
IP address only, then creating an InetAddress from that, which is
triggering reverse DNS lookup again to find out how to contact the
hostname (e.g. should we use a socks proxy or not).