Skip to content

One of Neuron ESB’s scalability features is the ability to install multiple instances of the Neuron ESB Runtime on a single server. Each runtime instance can be configured as either a 32 or 64-bit process, capable of running side by side. Each instance of the runtime can load an independent Neuron ESB Configuration store (solution). This allows organizations to easily partition business solutions to run on a single server and scale across multiple servers. Read more below about Port Sharing.


However, one of the configuration challenges has always been TCP port configuration at the solution level. Neuron ESB uses TCP ports to communicate between its internal subsystems e.g. Auditing, Control, Configuration, Master and TCP Publishing Services. Remote Neuron ESB Parties also use TCP to connect to the Neuron ESB Server; to retrieve their respective configuration, receive updates and to regularly send reporting information. The TCP Port configuration for a solution can be found on the Ports tab of the Enterprise Zone by navigating to Deployment->Settings->Zones within the Neuron Explorer.


Prior to CU4, if multiple instances were installed on a single server, users would need to ensure that the ports configured for each solution assigned to those instances were unique. For example, if the Bootstrap Service was configured in one solution (instance A) to run on port 50000, then the other solution (instance B) would need to be configured to use a different port. If they weren’t, then one of the solutions would fail to start, reporting a Port in use exception.

The unique port requirement made it more challenging, operationally, to manage the solutions as more runtime instances were installed on a single server. To resolve the need to change and manage port conflicts between solutions we are introducing Port Sharing in the 3.5 CU4 release. Port Sharing can significantly reduce the operational and management overhead when installing and running multiple instances of the Neuron ESB Runtime on the same machine.

Port Sharing is easily enabled by doing 2 things

  1. Enable and then set for automatic startup the “Net.TCP Port Sharing Service” in the service control manager. Start the service. For more information:
  2. Enable the new Port Sharing option located on the Port tab of the Enterprise Zone within the Neuron ESB Explorer as shown below:

Once the Port Sharing option is enabled, the solution must be saved and the runtime instance assigned to it restarted.

Organizations using the Neuron ESB Party API directly in their .NET applications will be required to append the name of the runtime instance to the service address url. For example, previously the service address would look similar to following if the runtime instance name was “default64”:



<add key="esbZone" value="Enterprise"/>

<add key="esbServiceAddress" value="net.tcp://localhost:50000"/>

<add key="esbServiceIdentity" value=""/>


If Port Sharing is enabled, the service address would now look like this:



<add key="esbZone" value="Enterprise"/>

<add key="esbServiceAddress" value="net.tcp://localhost:50000/default64"/>

<add key="esbServiceIdentity" value=""/>


Lastly, the other implication to consider is performance tuning. When Port Sharing is disabled, performance tuning for the Neuron ESB internal subsystems is controlled by modifying the “Internal Service Binding Settings” located on the Server tab of the Enterprise Zone as shown below. These parameters are typically modified to reflect the number of CPUs/Cores balanced against the load being placed on the services.


However, when Port Sharing is enabled, the SMSvcHost.exe, (which hosts the Net.TCP Port Sharing Service) manages the TCP sockets on Neuron ESB’s behalf. This means that performance tuning will be controlled by the binding settings within the SMSvcHost.exe.config file. For more information regarding the configuration of tuning parameters and the creation of the config file: .

The new Port Sharing option will greatly simplify the creation, deployment and management of multiple Neuron ESB runtime instances and solutions on individual servers!


About the Author

Author's Name
Marty Wasznicky


Marty has almost 30 years of experience in the software development industry. He joined Peregrine Connect after six years as a Regional Program Manager in the Connected Systems Division at Microsoft. His responsibilities there included building out Microsoft’s BizTalk Server product integration business, managing a team of SOA/ESB/BPM field specialists and building strategic partner alliances. Marty created the Microsoft Virtual Technical Specialist program and owned the development of Microsoft’s Enterprise Service Bus Toolkit.

Read more about Peregrine Connect

  • Rabbit MQ Topics

    Introduction Due to the open-source nature of RabbitMQ and constant updates, it is...

  • Port Sharing

    One of Neuron ESB’s scalability features is the ability to install multiple...

  • The Integration Journey to...

    The Integration Journey to Digital Transformation with Peregrine Connect

  • Saving Time and Money by...

    Neuron ESB Application Integration and Web Service Platform: A Real-World Example...

  • Elektro Gorenjska

    Peregrine Connect Eliminates Over 30% of Point-to-Point Integrations and reduces...

  • D&H Distributing

    Modernizing operations integration to increase volume transactions by 2X

  • video-icons-wrapper

    Decision Test Data Mapping

    - Use decisions to drive the execution of...

  • video-icons-wrapper

    Map Testing

    Learn how to utilize FlightPath's testing functions...