archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <>
Subject Fwd: Error transferring file: Connection timed out
Date Mon, 03 Jan 2011 22:13:16 GMT
Sorry to those that will see this twice. I manually replied to the dev list
first time around by mistake.*

I trust the connection problems are real, but I'm not convinced this is an
Archiva issue based on the information you have provided. I have seen this
happen using the Sun JVM when a DNS entry is updated with a new IP address.
The Sun networking APIs cache results for successful DNS lookups unless you
configure it otherwise. When you restart the VM, the cache is wiped which
would explain why it started working after that.

1.) Were you using the Sun JVM?
2.) Did you configure it to disable DNS caching?
3.) Did the DNS entry change for that repo while the server was running?

Information on how to configure.disable sun networking code in Java 6 VM:

Hope this helps,


This subject is not true.

Hey folks,

I'm running Arichva 1.3.1 in Tomcat 6.0.18 (jdk 1.6.0_18-b07 on
I'm getting tons of ``errors'' of this kind:

2010-12-29 14:28:00,528 [http-80-14] WARN
 org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors  - Transfer
error from repository "opensaml-repo" for versioned Metadata
com/bw/stuff/stuffFullEA/maven-metadata.xml, continuing to next repository.
Error message: Download failure on resource []:Error<>transferring
file: Connection timed out (cause:
Connection timed out)

The funny facts:

*) "opensaml-repo" is the last in the list, yet it's causing downloads of
this file to hang, and builds to fail (maven is far less patient than a

*) when running curl, I'm getting a 404 (as expected), NOT a timeout.

*) first two repositories are the ones we're trying to replace by archiva.
They deliver the document within miliseconds.

*) This does not only to happen with the maven-metadata.xml file - but only
for text files, not for binary files
(.pom, .sha1)

*) it only happens for opensaml-repo

*) it stopped happening after a restart of Tomcat.

Upgrade to 1.3.3 is planned, yes. But: Will it mitigate these errors?

I really don't like to use my users as a monitoring system.
(It's very hard to monitor this kind of behaviour automatically, since it
doesn't happen for all files consistently.)

So long,


Igor Galić

Tel: +43 (0) 664 886 22 883
URL: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message