Repository Management with Nexus

7.1. Introduction

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.

The Smart Proxy feature replaces this constant polling approach with a
Publish/Subscribe-based messaging approach between Nexus 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 Nexus instances.