You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Marc Wirth (JIRA)" <ji...@codehaus.org> on 2010/03/16 13:44:23 UTC
[jira] Created: (MNG-4592) Snapshot artifacts that could not be
downloaded due to communication problems are "blacklisted" for a day by
default.
Snapshot artifacts that could not be downloaded due to communication problems are "blacklisted" for a day by default.
---------------------------------------------------------------------------------------------------------------------
Key: MNG-4592
URL: http://jira.codehaus.org/browse/MNG-4592
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0-alpha-7
Reporter: Marc Wirth
If an artifact could not be downloaded because of communication problems with the server Maven should not use the update check intervall before rechecking.
The fix for http://jira.codehaus.org/browse/MNG-3421 introduced a behaviour that has cost us some time to find a solution. We're facing network problems with one of our nexus servers and this results by default in a 24 hour "blacklisting" of that artifact. For a continuous integration scenario this is rather painful (build stays red for a whole day) and using a different policy increases the network overhead because then all snapshots are checked. For now we have a very ugly workaround that simply deletes all *.lastUpdated files from the local repository.
A better solution from our point of view would be to only write the lastUpdated file if the resource really doesn't exist (DefaultWagonManager#getRemoteFile() threw ResourceDoesNotExistException?), but not if the wagon reported a communication problem (TransferFailedException?). That way the solution to MNG-3421 should still be valid, but without blocking CI in our case.
It would also be rather helpful if the real cause for such delayed lookups would be reported by default ("Failure to resolve ... was cached in the local repository. Resolution will not be reattempted until ..."). In our case we only had the standard error message in the log that the artifact could not be resolved from any repository and it took us a while to figure out that this was really because of the lastUpdated-check.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4592) Snapshot artifacts that could not be
downloaded due to communication problems are "blacklisted" for a day by
default.
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann closed MNG-4592.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0-beta-4
Assignee: Benjamin Bentmann
Fixed in [r995606|http://svn.apache.org/viewvc?view=revision&revision=995606]. As suggested, only the not-found case is cached, other transfer errors aren't and will have resolution be retried during the next build.
> Snapshot artifacts that could not be downloaded due to communication problems are "blacklisted" for a day by default.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4592
> URL: http://jira.codehaus.org/browse/MNG-4592
> Project: Maven 2 & 3
> Issue Type: Bug
> Affects Versions: 3.0-alpha-7
> Reporter: Marc Wirth
> Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-4
>
>
> If an artifact could not be downloaded because of communication problems with the server Maven should not use the update check intervall before rechecking.
> The fix for http://jira.codehaus.org/browse/MNG-3421 introduced a behaviour that has cost us some time to find a solution. We're facing network problems with one of our nexus servers and this results by default in a 24 hour "blacklisting" of that artifact. For a continuous integration scenario this is rather painful (build stays red for a whole day) and using a different policy increases the network overhead because then all snapshots are checked. For now we have a very ugly workaround that simply deletes all *.lastUpdated files from the local repository.
>
> A better solution from our point of view would be to only write the lastUpdated file if the resource really doesn't exist (DefaultWagonManager#getRemoteFile() threw ResourceDoesNotExistException?), but not if the wagon reported a communication problem (TransferFailedException?). That way the solution to MNG-3421 should still be valid, but without blocking CI in our case.
>
> It would also be rather helpful if the real cause for such delayed lookups would be reported by default ("Failure to resolve ... was cached in the local repository. Resolution will not be reattempted until ..."). In our case we only had the standard error message in the log that the artifact could not be resolved from any repository and it took us a while to figure out that this was really because of the lastUpdated-check.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira