Nexus 1.6 introduces Auto blocking unreachable remote repositories

April 29, 2010 By Brian Fox

3 minute read time

In Nexus 1.6, we reintroduced a useful little feature that had been available in early 1.0 betas: The ability to have Nexus auto block proxies that are unreachable. What's improved in this version is the ability to control this feature and the fact that it will auto unblock the repo once it becomes reachable again.

Whenever an artifact is downloaded from a proxy repository, it is automatically cached locally and used to serve subsequent requests. Nexus will continue to serve the artifact until it expires based on the configuration (release artifact typically never expire).

When new artifacts are being requested that Nexus has never seen before, it will look in the proxies to locate it (this behavior can be optimized with routing rules). If the remote request times out, Nexus by default will check two more times before giving up. This is usually enough to handle transient network glitches. If however, the repository is down for an extended period of time, all these retries can back up the connections and slow down over all performance. This is where the auto block comes in.

Whenever Nexus detects a connection is timing out, or receives repeated failures from the remote (for example 500 errors), it will mark this repository as unavailable. All subsequent requests to this proxy will be served from the local cache only. In almost all cases, this is sufficient for your builds to continue unaffected.

Once a repository is marked unavailable, a thread is spawned to proactively monitor its status. In this first release, we wanted to make this feature easy to use and not introduce too many confusing configuration options. We chose a fibinaci type of behavior as the best way to monitor the remote, balancing responsiveness and not pounding the remote with repeated requests at the same time (since we deal with constant abuse of Central, we are sensitive to making Nexus a good repository citizen). We start with a delay of 10 seconds before rechecking the remote, then it will check again in 20,30,50,80,130 seconds, each time adding the delay of the two previous checks. Obviously the administrator can force a proxy to be available again at any time.

In the Nexus server configuration panel, it is possible to define an email address that should be notified of system events. The autoblock feature uses this address to notify of remote repository status changes. To avoid spamming the user for connections that may be flakey, we won't notify until two retries have failed (ie 30 seconds + the 3 attempts that triggered the blockage). Once the repo is back up, the administrator is also notified.

Nexus monitors the status of a repository by issuing HEAD and GET requests against the root url of the repository. Some systems may not respond correctly to this request, rendering the monitoring ineffective. If you have this type of repository defined, or have a known flaky connection, you may disable the auto blocking feature in the proxy configuration.

Tags: repository manager, Nexus Repo Reel, nexus 1.6

Written by Brian Fox

Brian Fox is a software developer, innovator and entrepreneur. He is an active contributor within the open source development community, most prominently as a member of the Apache Software Foundation and former Chair of the Apache Maven project. As the CTO and co-founder of Sonatype, he is focused on building a platform for developers and DevOps professionals to build high-quality, secure applications with open source components.