On 16/07/2011, at 9:11 PM, Cristiano Costantini wrote: > Hi Brett thank you for your reply (I admit it, I explicitly quoted a > sentence from your book for raising your attention ;-) )
:) > It seems that the Repository Group with two Managed Repositories containing > remote Proxy Connection, does not work well as a cache: if the artifact is > found on the second of the two Managed Repositories, requesting the artifact > to the Repository Group makes Archiva first search the artifact on the first > Repository, which make HTTP requests (returning 404), and then search the > Artifact on the second Repository, where the cache works (Archiva make no > more HTTP requests). I think this behaviour is correct though - if we were to cache a 404, the artifact might be there later. I've generally found it to be more confusing when that is the way it is configured. Instead, we encourage ordering the repositories (both in the proxy connectors and the groups) to give the most likely hit first, and to use whitelists to increase the likelihood of a hit (or a legitimate skip) of a repository. > > My first set-up was intended to separate all the artifacts coming from > unknown/untrusted repositories so that I can (try to) eliminate them from my > dependencies. > The second set-up solves slowness issues but now I can't no more investigate > on the dependencies coming from these repositories... I'm not quite sure what you mean - how did you investigate the dependencies before that you can't now? I think the pattern of one managed repo to one proxy is generally a good idea... > > Another question, which may be a work around for me: is there a possibility > to know from which URL a cached artifact has been downloaded? Does Archiva > logs this information? Does it would be easy to write a fix by myself? If you are using one repository per remote proxy, I would have thought that would make it clear - so perhaps I'm misunderstanding what you are looking for. - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
