Archiva

blacklisting unavailable remote reps

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0.2
  • Fix Version/s: 1.4
  • Component/s: repository interface
  • Labels:
    None
  • Number of attachments :
    0

Description

once one of the repos configured as a proxy-connector is down, the mvn build-process slows down extremely as the connect time-out is about 1 minute (for each repo and each artifact).
There should be a configuration available to adjust blacklisting repos that have been identified as non-reachable.
Such repos should be able to get re-avtivated manually.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MRM-830 Archiva is very slow when remote repository is unreachable

  • Critical - Crashes, loss of data, severe memory leak.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MRM-1067 Archiva fails to properly deal with overloaded upstream proxy

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Task - A task that needs to be done. MRM-1347 Migrate repository proxy to the new repository API

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

we already have the "cache failures" option - this should address your needs

Show
Brett Porter added a comment - we already have the "cache failures" option - this should address your needs
Hide
Permalink
Marc Lustig added a comment -

Not quite. The use-case is not "unable to find artifact x on remote-repo y".
The use-case is "cannot connect to the remote-repo due to server-unavailability".

The alterative would be to manually check every hour if all the remote repo's that are configured are still available

Ideal solution: custom cron-task to (asynchronously) check the availability of all the remote repos.
Once a connect fails, the sys-admin should get an email-notification
"Warning: remote-repository y is currently down and has been locked! Unlock repository [Link to page to unlock the locked repository]"

Please re-open. Ty.

Show
Marc Lustig added a comment - Not quite. The use-case is not "unable to find artifact x on remote-repo y". The use-case is "cannot connect to the remote-repo due to server-unavailability". The alterative would be to manually check every hour if all the remote repo's that are configured are still available Ideal solution: custom cron-task to (asynchronously) check the availability of all the remote repos. Once a connect fails, the sys-admin should get an email-notification "Warning: remote-repository y is currently down and has been locked! Unlock repository [Link to page to unlock the locked repository] " Please re-open. Ty.
Hide
Permalink
Brett Porter added a comment -

reopening for investigation. This is the intent of the feature - it should blacklist a resource on 4xx errors, and a repository on 5xx errors (with an expiry time)

Show
Brett Porter added a comment - reopening for investigation. This is the intent of the feature - it should blacklist a resource on 4xx errors, and a repository on 5xx errors (with an expiry time)
Hide
Permalink
Brett Porter added a comment -

we currently have no way to tell what is a resource error and what is a repository error, so it is cache failures per resource. We're not tracking timeouts as separate errors.

Moving this out to do some more advanced analysis of remote state for managing connections

Show
Brett Porter added a comment - we currently have no way to tell what is a resource error and what is a repository error, so it is cache failures per resource. We're not tracking timeouts as separate errors. Moving this out to do some more advanced analysis of remote state for managing connections
Hide
Permalink
Brett Porter added a comment -

also note that we now have the ability to take a remote repo offline. This can be done manually, but we may also want to hook these two features together.

Show
Brett Porter added a comment - also note that we now have the ability to take a remote repo offline. This can be done manually, but we may also want to hook these two features together.

People

  • Assignee:
    Unassigned
    Reporter:
    Marc Lustig
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: