Rabbit MQ Topics

Neuron ESB provides a hierarchical, Topic-based publish and subscribe model to mediate the routing of messages between Parties (Publishers and Subscribers that are hostable in .NET applications), Adapter, Service and Workflow Endpoints. Topic-based messaging can be a great way of abstracting endpoints from one another. In essence, all endpoints become publishers and subscribers with one never having to have knowledge of the other. This allows organizations to easily change and modify existing solutions without interrupting the processing of other endpoints.

Neuron ESB is unique in that the Quality of Service and underlying Transport of Topics can be changed to better accommodate and more closely align with the business requirements of specific use cases. For example, durable, guaranteed, and reliable messaging as well as in-memory routing of messages, can be provided by simply changing the Transport property of a Neuron ESB Topic as shown below:

When changes are made, the underlying Party API is self-aware of changes made at the server and auto-configures itself to accommodate the Topic configuration changes, even when deployed and hosted on remote machines. This means that developers using the Party API do not need to know, nor do they directly have to work with or individually program the underlying transport configuration, transaction or QOS requirements. This is all controlled and managed at the server level. For the user who needs to publish messages, the code is as simple as this:

// Create an instance of a publisher

using (Publisher publisher = new Publisher("MyPublisher"))

{

// catch any exceptions that may occur while connecting

// to each individual topic

PartyConnectExceptions exceptions = publisher.Connect();

if (exceptions.Count < 1)

{

publisher.Send("MyTopic", "<Test>My Request</Test>");

}

else

{

// log the errors

}

}

Neuron ESB 3.5 provides a number of Transports that users can select for Topics including Named Pipes, TCP, Peer, Rabbit MQ and MSMQ. Some provide durable, guaranteed, and reliable messaging such as MSMQ and Rabbit MQ. In the CU4 release, the Rabbit MQ Transport for Topics has been completely refactored to provide not only better performance, new manageability, and more flexibility, but also better fault tolerance, reliability and security.

Updated Version Support

In the CU4 release, the first notable change is that our support for Rabbit MQ has been upgraded to support Rabbit MQ version 3.5.6 and Erlang 18.1. Using the Neuron ESB installer, users can optionally select to install these during the setup process, or can download these from the locations list in our readme.html file or directly from the Rabbit MQ website.

Configuration

The Rabbit MQ configuration for a Deployment Group can be found on the RabbitMQ tab of a Deployment Group by navigating to Deployment->Environments->Deployment Groups within the Neuron Explorer.

When registering Rabbit MQ servers for a Neuron ESB Deployment Group the following information is required:

Property	Description
Server	Name of the Rabbit MQ Server
Port	Port of the Rabbit MQ Server. -1 will use the default Rabbit MQ port of 5672
Mgmt Port	Port of the Rabbit MQ Management Portal. Default is 15672
vHost	The configured vHost of the Rabbit MQ Server. Default value is “/”
Username	Username to access Rabbit MQ.
Password	Password to access Rabbit MQ

Although some properties may seem fairly straight forward, others may not. For instance, the “Mgmt Port” represents the port of the Rabbit MQ Management Plugin. Neuron ESB requires this to be installed and configured for every Rabbit MQ server registered as it uses it to query for the health and message throughput rates which appear in both Endpoint Health and the Rabbit MQ Message Management console in the Neuron ESB Explorer. More information regarding the Rabbit MQ Management Plugin and how to install it can be found here: https://www.rabbitmq.com/management.html

As of Rabbit MQ version 3.3.3, the default username “Guest” cannot be used against the Rabbit MQ management plugin if the server name is anything other than “Localhost”. It is always recommended to create a dedicated username and password in Rabbit MQ that can be used by Neuron ESB.

High Availability and Failover

Neuron ESB allows users to enter multiple instances of Rabbit MQ servers to support the mirroring of the underlying queues that Neuron ESB will use for the Publishers and Subscribers created within the Neuron ESB Explorer. Rabbit MQ uses mirroring, rather than Windows Failover Clustering, to achieve High Availability of messages. More information regarding Rabbit MQ HA and its configuration can be found here: https://www.rabbitmq.com/ha.html

When multiple servers are configured, at runtime Neuron will use the first server it can connect to as the primary message server. If for any reason that server becomes unavailable, Neuron ESB will automatically failover over the next server in the list until it can find one that it can establish a connection against. If a connection can be established, publish and subscribe activities remain undisrupted at runtime; messages will not be lost and the failover will be invisible to the processes and users of Neuron ESB. Internally we detect connection issues and then cache and resend the messages when we fail to receive the original acks/nacks from the Rabbit MQ servers.

Multiple Environments and VHosts

New to CU4 is the inclusion of the vHost property. A common practice by some Rabbit MQ users is to establish specific vHosts to mirror their deployment environments. For example, there may be a vHost named “Development”, “QA” and “Production”. By supporting Rabbit MQ vHost environments, Neuron ESB users can easily map Neuron ESB deployment groups to their respective vHost environments. This will functionally isolate the underlying queues and exchanges that Neuron ESB creates for one deployment group from another on the same Rabbit MQ server instance.

Once the Rabbit MQ servers are registered with a Deployment Group, Topics and Parties can be configured to use the Rabbit MQ Transport.

Neuron ESB Topic Configuration

The Rabbit MQ Transport configuration is located on the Networking tab of the Topic by navigating to Messaging->Publish and Subscribe->Topics within the Neuron Explorer.

Property	Category	CU4	Description
Delivery Mode	Publish	*	Persistent (i.e. Durable) or NonPersistent. Persistence ensures message is written to disk. If using Transactions, Persistence SHOULD be used.
Transaction Type	Publish	*	Controls the level of reliability for messages. Either ‘None’, ‘PublisherConfirms’ or ‘Transactional’ can be selected. ‘PublisherConfirms’ uses an asynchronous Ack/Nack protocol while ‘Transactional’ forces a commit/rollback on each message published.
-Batch Size	Publish		Only for use with PublishConfirms type of transactions. The number of messages that will be published to Rabbit MQ in a Publish Confirm transaction
-Batch Confirm Timeout	Publish	NEW	Only for use with PublishConfirms type of transactions. The number of seconds to wait after the Batch of messages have been published to receive all ACKs/NACKs from Rabbit MQ. Should be a value between 1 and 60.
-Inactivity Timeout	Publish	NEW	Only for use with PublishConfirms type of transactions. The number of minutes to wait after the last message sent before checking to determine if all ACKs/NACKs from Rabbit MQ have been received. Should be a value between 1 and 5.
-Resubmit UnAck’d Messages	Publish		Only for use with PublishConfirms type of transactions. If true and ‘Detect Duplicates’ are selected, messages that were published but were not acknowledged will be republished. This should only occur when dealing with clustered/mirrored Rabbit MQ instances. The republish would occur when a connection is reestablished with another server in the cluster.
Time To Live	Publish		A value in minutes that specifies how long messages are valid for delivery before they are expired (dead letter) and transferred as a failed message into the Neuron ESB database.
Must be Routable	Publish	NEW	If set to true, the message must be routable by Rabbit MQ. If the message cannot be routed to a destination queue, it will be stored as a failed message into the Neuron ESB database. **This will incur a significant performance penalty. This should NEVER be needed as Neuron ESB will dynamically create any missing queue or exchange on startup.
Prefetch Size	Receive	NEW	The number of messages that will be prefetched from the queue to transport layer. A value of 0 means unlimited.
-Detect Duplicates	Receive		Only for use with PublishConfirms type of transactions. If true, duplicate messages received by the Neuron ESB Party will be discarded. This can be used to provide once only delivery.
-Detection Window	Receive		Only for use with PublishConfirms type of transactions. The amount of time (in minutes) in which previously received message meta data will be maintained in memory to search against for duplicate messages.
-Report Duplicates	Receive		Only for use with PublishConfirms type of transactions. If true, if a duplicate message is discovered it will be logged as a Warning in the Neuron ESB Windows Event log.
SSL Enabled	Security	NEW	Connect to Rabbit MQ Server using only SSL
-Port	Security	NEW	SSL Port for all Rabbit MQ server connections
-SSL Protocol	Security	NEW	SSL Protocol to use for all Rabbit MQ server connections.
-Client Authentication	Security	NEW	Require Neuron ESB to provide Rabbit MQ Server a client certificate to authenticate against.
-Certificate	Security	NEW	Select a client certificate configured in the Security section of the Neuron ESB Explorer to authenticate against the Rabbit MQ Server.
-Passphrase	Security	NEW	Passphrase for the client certificate, if one exists

In the CU4 release a number of new properties have been added, some changed (*), others removed

The values of these properties control how the Rabbit MQ transport functions for each Publisher or Subscriber that has a subscription to the configured Topic. In the CU4 release the following properties were removed because they were no longer relevant:

• Failed Message Path
• Auto Acknowledge

For greater clarification of their respective capabilities, the Recoverable property was renamed to Delivery Mode and Reliability Mode was renamed to Transaction Type. Also, in previous versions a user could only select to use Transactions if the persistent messaging was also selected. In CU4, that is no longer a requirement.

In most cases though then internal implementation of most of these properties have changed to provide, better performance, scalability, reliability and fault tolerance.

Management

In previous versions, the Neuron ESB Rabbit MQ Transport channel would dynamically create the necessary underlying Rabbit MQ based infrastructure (e.g. Queues, Exchanges, Bindings, etc.) anytime a Neuron ESB Party connected to the bus or, when the Neuron ESB Topic started up. This eliminated the need for administrators to manually create and maintain the Rabbit MQ infrastructure Neuron ESB required. Consequently, this made the underlying Rabbit MQ Transport virtually invisible to anyone using the Neuron ESB Party API, and alleviated the need for administrators to manage additional infrastructure requirements.

However, what Neuron ESB did not do was keep the infrastructure in sync with changes made within the Neuron ESB Explorer. For example, if Topics/Parties were either renamed or deleted, their respective Rabbit MQ Queues and Exchanges would remain, unchanged and orphaned. If renamed, Neuron ESB would simply create a new set of Queues and Exchanges to use. If there were messages in the old Queues, they would remain but would have to be dealt manually by administrators.

Neuron ESB also created an unnecessary extra set of Queues and Exchanges if the Recoverability property was set to True. All of this has been changed in the CU4 release.

Naming Conventions

The first notable change that we made in the CU4 was renaming of the underlying Rabbit MQ Queues and Exchanges. In previous versions of Neuron ESB, Queues and Exchanges used the following naming conventions:

Rabbit MQ Exchanges:

<InstanceName>.<Zone>.<Topic>.d.ad

Rabbit MQ Queues:

<InstanceName>.<Zone>.<Topic>.<Party>.d.ad

Where:

• InstanceName = Name of the Neuron ESB runtime Instance running the solution
• Zone = The name of the Neuron ESB Zone within the solution
• Topic = The name of the Neuron ESB Topic within the solution
• Party = The name of the Neuron ESB Party within the solution
• d = The “d” is appended if the Neuron ESB Topic was configured to be persistent
• ad = The “ad” is appended if the Neuron ESB Topic was configured to be deleted when Parties are no longer connected to the Topic

In the CU4 Release the naming conventions have been simplified to the following, eliminating the unnecessary extra sets of Queues and Exchanges to be managed:

Rabbit MQ Exchanges:

NEURON.<InstanceName>.<Topic>

Rabbit MQ Queues:

NEURON.<InstanceName>.<Topic>.<Party>

Synchronization

New in the CU4 release is the full management of the Rabbit MQ infrastructure Queues and Exchanges used by Neuron ESB. Previously, Neuron ESB would only create their respective dependent Rabbit MQ Queues and Exchanges on startup as well as when any Party connected to the bus. Neuron ESB now additionally handles renaming and deleting these if their respective counter parts within the Neuron ESB Explorer (e.g. Topics, Publishers and Subscribers) are renamed or deleted. For deletions, Neuron ESB will delete its respective underlying Rabbit MQ Queues only if there are no messages that remaining in the Queue.

Performance and Reliability

A number of internal changes have been made to the Rabbit MQ Transport to enhance reliability, error reporting, and functionality while at the same time significantly increase the performance of certain operations and message throughput.

Serialization Format

One of the first changes made was to the serialization method that Neuron ESB uses to interact with the underlying Rabbit MQ infrastructure. Previously, Neuron ESB serialized the entire Neuron ESB Message using Binary Serialization. With the introduction of CU4, this has been changed to a custom serialization method where only the body of the Neuron ESB Message is published, while the necessary internal Neuron ESB Message headers are custom serialized as Rabbit MQ custom header properties. This has several advantages; reduces CPU utilization, allows for the message body to be accessed without proprietary methods and reduces the overall payload size that the underlying Rabbit MQ infrastructure has to work with.

Publish Confirm Transactions

The Neuron ESB Rabbit MQ Transport supports both Transaction types that Rabbit MQ offers; their channel based Transaction model as well as their batched style Transaction model e.g. Publish Confirms. Both are Acknowledge, Negative Acknowledgement (ack/nack) based models. Users can learn more about Publish Confirms here: https://www.rabbitmq.com/confirms.html , as well as why Rabbit MQ introduced them: http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms .

In CU4 a number of enhancements were made to the Publish Confirm model to make it more reliable as well as more performant. Neuron ESB now handles the ack/nack reconciliation process more efficiently, especially where multiple acks/nacks are received on a single event, alleviating unnecessary locking on the collection of messages we have to maintain internally. The CU4 release also exposes additional properties that can be used to finely tune the performance and throughput as well the reliability of the batch transaction such as “Batch Confirm Timeout” and “Inactivity Timeout”. These properties force Neuron ESB to call into Rabbit MQ for it to finish sending any pending acks/nacks, and only then do we resubmit the messages that we’ve neither received acks or nacks for. Messages we receive nacks for or where we’re notified by Rabbit MQ that that message is undeliverable, are automatically moved into the Neuron ESB Failed database table.

Receiving messages

In previous versions, the underlying Neuron ESB Rabbit MQ Transport would receive messages for its respective Neuron ESB Parties (or Dead Letter processing) by creating an underlying consumer and continually polling the queue. In CU4, this has been changed to use Rabbit MQ’s new event based consumer.

Dead Letter Processing

The CU4 Rabbit MQ Topic transport implementation includes a custom Dead Letter processor, Exchange and Queue to handle those messages delivered to Subscribers that exceed the configured Time to Live property. These messages are automatically detected and moved into the Neuron ESB Failed Message database table.

These messages will be available to be queried, viewed, modified and resubmitted by using the “Failed Message Viewer” window launched from the Failed Messages report located by navigating to Activity->Database Reports->Failed Messages within the Neuron ESB Explorer.

The messages recorded will have an Exception Type of “Dead Letter”. The failure message will contain failure details such as the name of the underlying Queue and the associated Exchange that the message expired in as well as the date-time stamp indicating when the message expired.

CU4 Performance Comparison

The latest Neuron ESB public release was tested against the CU4 release using a relatively underpowered non-server grade machine configured with 16GB RAM, Windows 7 64 bit, Dual CPU (quad core). The results of the testing can be found in the table below:

Configuration	Messages Sent/Received	Message Size (Bytes)	CU3 (msg/sec)	CU4 (msg/sec)
No Persistence/No Transactions	500,000	100	4,550	12,000
No Persistence/No Transactions	500,000	1024	4,200	9,400
Persistence/No Transactions	500,000	100	4,400	8,500
Persistence/No Transactions	500,000	1024	4,075	7,900
Persistence/Publish Confirm Transactions/Batch Size = 1000	500,000	100	1,750	3,000
Persistence/Publish Confirm Transactions/Batch Size = 1000	500,000	1024	1,300	3,000

Basic Improvements

A variety of improvements for the Neuron ESB Rabbit MQ Transport have been included in the CU4 release. For example, Request/Response type message communication when using Neuron ESB Sub Topics was not supported in previous releases. Neuron ESB now monitors more events from Rabbit MQ to better respond to error conditions for everything from resource constrictions to unanticipated shutdown events. Failed message auditing has been refactored to decrease the opportunity for faults to occur when attempting to store failed or dead letter messages to the Neuron ESB failed database table

Security

With CU4’s support for Rabbit MQ 3.5.6 comes support for SSL. SSL can be enabled in the Transport Properties located on the Networking tab of the Topic by navigating to Messaging->Publish and Subscribe->Topics within the Neuron Explorer.

Once SSL has been enabled, the Rabbit MQ SSL port needs to be provided and the SSL Protocol to use must be selected. Although Neuron ESB and Rabbit MQ supports both SSL2, SSL3, TLS, TLS 1.1 and TLS 1.2 by default SSL3 support is disabled by Rabbit MQ to avoid POODLE attacks. More about Rabbit MQ and its SSL support can be found here: http://www.rabbitmq.com/ssl.html

Client Authentication can also be enabled by providing a Certificate (registered within the Security section of the Neuron ESB Explorer).

Configuring SSL support is done by modifying the Rabbit MQ configuration file as well as registering several important Environment Variables for the machine. More information can be found here: http://www.rabbitmq.com/configure.html.