Skip to main content

Scaling Repositories

When there is a requirement to have many Docker registries it potentially leads to configuring many repositories using many different connector ports. These connector ports are setup within NXRM and use the connector thread allocation logic of the underlying Eclipse Jetty. The default thread pool size, that Eclipse Jetty draws from to preallocate threads for the new connector, is 400. Our support article Understanding Eclipse Jetty 9.4.8 Thread Allocation gives really good details on how allocation works and why at certain amount of repositories with connectors the pool can get maxed out and IllegalStateExceptions maybe seen indicating that there are Insufficient configured threads.

Reverse Proxy (recommended)

Placing a reverse proxy in front of NXRM dynamically maps docker requests to NXRM Docker repositories. Using a reverse proxy does not require port numbers to be specified and therefore no new connectors on your docker repositories are required. There are two strategies that can be used, the Port Method and the Subdomain Method. See Docker Repository Reverse Proxy Strategies for more details on these strategies.

Changing the thread pool size

Knowing that there is a limit to the amount of connectors that can be used in conjunction with how threads are being allocated for them from the Eclipse Jetty thread pool gives us a clear indication that we are able to make changes to the configuration of the thread pool. This can be achieved by editing the configuration file ($install-dir/etc/jetty/jetty.xml) and add a new maxThreads setter (a restart of NXRM is required to pick up changes to the file)

<Arg name="threadpool">
    <New id="threadpool" class="org.sonatype.nexus.bootstrap.jetty.InstrumentedQueuedThreadPool">
        <Set name="maxThreads">400</Set>
    </New>
</Arg>

Note

Changing the thread pool size can help with small scaling efficiencies but is not a sustainable solution for scaling performance and we suggest being conservative increasing the maximum threads as each new thread in the pool has the potential to increase workload inside of NXRM for concurrent request threads.