Repository Management with Nexus
Default is Polling
Typically an organization runs a single Nexus instance to proxy external components as well as host internally produced components. When a build is running against this Nexus 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 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 you expiration times to zero and constantly polling.
Smart Proxy Introduces Publish-Subscribe
Increasingly, Nexus 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 instance. This local instance hosts its own components and proxies the other servers.
An example deployment scenario is displayed in Figure 7.7, “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 Nexus instances sharing a mutual trust. The result is a significantly improved performance due to nearly immediate availability of upstream artifact information directly in the downstream Nexus instances.