Smart Proxy in Nexus Repository 2

Typically an organization runs a single Nexus Repository Manager Pro instance to proxy external components as well as host internally produced components. When a build is running against this instance, it will look for any new components in the proxied remote repositories. This adds additional network traffic that in many cases will just be a response from the remote server indicating that there are no changes.

This polling approach is fine for smaller deployments. It will not result in immediately updated components as soon as they become available upstream. In distributed teams with multiple Nexus Repository Manager Pro instances, this delay can result in build failures and delays. The only way you are going to achieve that everything is up to date is by setting expiration times to zero and constantly polling.

Increasingly, Nexus Repository Manager Pro is used in globally distributed teams or used by projects that span multiple organizations. In many cases, it is advisable for each physical location to host its own Nexus Repository Manager Pro instance. This local instance hosts its own components and proxies the other servers.

An example deployment scenario is displayed in Figure 7.6, “Deployment Scenario for a Smart Proxy Use Case”. Using the traditional polling approach, specifically when used with snapshot repositories, can result in significant traffic and a performance hit for all involved servers.

The Smart Proxy feature replaces this constant polling approach with a Publish/Subscribe-based messaging approach between repository manager instances sharing a mutual trust. Once a component is published to a repository a message is sent to all subscribing in the smart proxy message queue that details the availability of new component. The subscribers are therefore immediately aware of any new deployment and can provide these components without having to poll the publishing server.

The result is a significantly improved performance due to nearly immediate availability of upstream component information directly in the downstream repository manager instances.