With the Nexus Professional 2.0 release, we’ve added a more intelligent approach to proxying repositories called Smart Proxy. When you configure a Smart Proxy you are establishing a relationship between two instances of Nexus.
To illustrate this feature, consider how a proxy repository works in Nexus 1.x: A traditional proxy repository has a very one-sided relationship with a remote repository. If a new artifact is published or modified on the remote repository, a traditional proxy has no way of knowing about changes unless it polls the remote repository. When you configure a proxy repository as a Smart Proxy in Nexus Professional 2.0 it can subscribe to change events published by a remote repository.
This post introduces Smart Proxy with an example of two, geographically distributed teams each maintaining a master instance which needs to proxy the other team’s instance. Once you understand this basic mechanism of behind Nexus Professional’s new Availability Architecture you’ll be able to plan and implement more complex deployments such as:
To illustrate how Smart Proxy works, suppose you have two Nexus instances: one in New York and one in Paris. Each instance supports an active group of developers. Both instances mirror Central and a handful of other remote repositories, and each instance maintains hosted release and snapshot repositories.
While both teams are collaborating with one another every day, let’s also assume that New York is working on a separate subsystem from the team in Paris. The New York team is building a web-based interface to a banking system that depends on some back-end functionality implemented by the team in Paris. The New York team is an internal “client” for the Paris team consuming libraries that facilitate access to a backend accounting systems. Both groups push release and snapshot artifacts to their own Nexus installations, and the New York team depends on snapshot artifacts from Paris.
This challenge is a common one. How do you support distributed development teams and share release and snapshot artifacts between these instances in a way that guarantees each instance has the most up to date snapshots and releases?
If the team in New York is depending on snapshots from Paris and vice versa, each Nexus instance has to proxy the other’s hosted repositories. This is where Smart Proxy comes to the rescue.
Traditionally, in Nexus 1 proxy repositories had to be configured to frequently poll the source repository for any changes. Caching timeouts for snapshot repositories in particular had to be set so low that there was little benefit to maintaining a local proxy cache of a remote snapshot repository. This was inefficient, it caused performance issues, and there was always a chance that the proxying side could be serving stale snapshots.
In Nexus 2.0, instead of frequent polling, these proxy repositories subscribe to change events from the source repository. One side registers interest in a collection of events published by the other side. In effect, your remote repository is now able to “push” change events to a proxying client.
The New York team’s proxy repositories are guaranteed to be up to date because the New york instance of Nexus is notified of changes immediately. When the French team pushes a new release or a new snapshot to Nexus, their instance notifies the other instance of a change event.
If an artifact has been deployed, deleted, or changed, the source repository notifies the proxy. If both teams proxy each other’s hosted repositories and configure Smart Proxy subscriptions, then both teams are assured that Nexus will never serve stale content.
This simple mechanism makes it possible to build complex distributed networks of Nexus instances relying on this publish/subscribe approach.
To learn more about Nexus Professional 2.0, go to http://sonatype.com/nexus.