Artifactory slow when remote repository does not respond

Hello all,
I'm quite new on Artifactory. I'm using it as a Maven proxy repository and I
access it through Gradle.
My Artifactory installation is proxying the following remote repositories:
- http://repo1.maven.org/maven2
- https://repository.jboss.org/nexus/content/groups/public/
- http://repository.springsource.com/maven/bundles/release
- http://maven.springframework.org/release
- https://maven.atlassian.com/repository/public
- http://www.smartclient.com/maven2
- http://repository.springsource.com/maven/bundles/external
- http://maven.restlet.org

These are the only remote repositories listed in Admin | Repositories |
Remote Repositories.

The problem is that whenever one of these sites have problems, Gradle takes
ages (tens of minutes) to resolve dependencies. Looking at the system
activities, I see that Gradle is waiting for replies by the Artifactory
repository. If I look at the Admin | Advanced | System Logs in Artifactory I
see a lot of errors like the following, repeating continuously at brief
distance in time:

2012-02-16 08:54:58,143 [pool-1-thread-18] [WARN ]
(o.a.r.RemoteRepoBase:359) - atlassian_maven_proxy: Error in getting
information for '<my pom>' (Failed retrieving resource from
https://maven.atlassian.com/repository/public/<my pom path>: Read timed out)

In this case it's the Atlassian repository that has problems. I can't
understand why when there's a "read timeout" problem or any I/O problem with
a repository, the failed connection does not get cached by Artifactory, even
if I set the "Failed Retrieval Cache Period" to 3600 seconds (that is, one
hour) into all the remote repository. I would expect that, if a repository
is not responding, Artifactory does not try to contact it again for an
hour... Instead, it tries again and again, so that any request coming from
Gradle takes a lot of time to be satisfied. I even lowered the "Socket
Timeout" setting to 5 seconds on each repository, however this helps very
little.
Sometimes I'm forced to temporarily set the "Offline" mode on the "broken"
repository in order to have Artifactory respond in a reasonable amount of
time... But this is a workaround, since I then must remember that I have to
re-enable it some time later...

Thanks in advance for any help.
Mauro.

P.S.: using Artifactory 2.5.0 (rev. 13086)

--
View this message in context: http://forums.jfrog.org/Artifactory-slow-when-remote-repository-does-not-respond-tp7290329p7290329.html
Sent from the Artifactory - Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users

Frederic Simon wrote

>
> Hi,
>
> Thanks for the feedback.
> Since many remote repository have different implementation per sub path,
> Artifactory is keeping the "Failed Retrieval Cache Period" per path. That
> is why you are seeing the multiple requests.
> Now your point is relevant, please open in our

> Jira&lt;https://issues.jfrog.org&gt;the relevant issue you'll be able to

> follow.
>
> In any case, to solve your issue at hand, I highly recommend adding
> include/exclude rules on the remote repositories for the list of
> groupId/artifacts you are expecting. This will tell Artifactory to
> completely stop sending request outside for irrelevant artifacts.
> So, since usually, most of the queries done by Gradle concerns your own
> SNAPSHOT artifacts, adding for example an exclude rule on the
> "remote-repos" virtual for all artifacts starting with your groupId will
> greatly improve your build time.
>
> Hope this help,
> Fred.
>

Hi Frederic,
thank you very much for your reply.
Actually I think that if a repository is not responding (read timeout, I/O
errors in general), the cache period should be considered valid for the
whole repository, because if the host is the same, I think it's quite hard
that one path works while another does not.

Regarding your suggested workaround to add include/exclude rules on the
remote repositories, it would be quite a lot of work (both to setup and to
maintain), since we're working with projects with dozens dependencies and
things change rapidly in our development process...

I opened the following JIRA issue:
https://issues.jfrog.org/jira/browse/RTFACT-4792
I really hope it could be addressed soon.

Thanks again!
Mauro.

--
View this message in context: http://forums.jfrog.org/Artifactory-slow-when-remote-repository-does-not-respond-tp7290329p7290453.html

Sent from the Artifactory - Users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users