Transaction based MSMQ messaging in Neuron

Replies to This Discussion

Permalink Reply by Martin Wasznicky on September 28, 2012 at 10:19am

This behavior is by design.  Neuron ships an event based pub/sub system.  unlike other pub/sub systems, we allow the architect to determine the underlying protocol/transport that drives the pub/sub system at the Topic level.  Hence once you create a topic, you can choose to either use TCP, Peer, Named Pipes, MSMQ or, in Neuron 3.0, AMQP.  There are pros/cons to using specific transports.  Some are obviously in memory....so no latency due to transactions or durability or other components required to be installed (i.e. TCP,Peer and Named Pipes).  Others can run headless when using the Party API...i.e. when I say headless I mean the Neuron ESB service could be down..yet you could still publish and receive messages. Peer supports this.,..as well as MSMQ when the direct property for the network transport is set to True.  Other transports offer optional durability and transaction support....Both MSMQ and AMQP are transports in that category.

Our goal with the Topic based pub/sub system is to abstract the network transport details from the User for the most part.  In other words...they are internal implementation details that you don't have to worry about.  At the end of the days, you create Topics with the characteristics and quality of service attributes you need, and under hood, the Neuron Parties (i.e. Publishers/Subscribers) communicate with Topics.  Topics control where a message is routed (i.e. what party or parties receive it) and how they receive it.

The underlying Party object manages the communication details of "how" to talk to a Topic...regardless of the properties or protocol that its configured for. Specifically so that the user doesn't have to know.

When you publish a message using our Party api (i.e. Publisher.Send()), in most cases you are sending a message to the Neuron ESB publishing service that represents the Topic.  The publishing service's job is to route the message to appropriate set of subscribers using the protocol/network configuration specified for that specific topic.  Subscribers are event based.  So when you hook into the OnReceive event, you're basically saying...I'm alive and I'm subscribing to messages so provide them as soon as they appear.  

If for example, you configured a Topic that the Subscriber is "subscribed" to with MSMQ as the network transport and you've set the transactions and durability properties to true, you will get reliable, guaranteed, end to end delivery of the message all the way through the OnReceive event.  Under the hood, we have physical queues that represent each party that can publish or subscribe to that topic.

if you want to abort receipt of the message, you can do one of three things; 1.) raise an exception in the OnReceive handler code....this will effectively rollback the transaction and roll back the message to the underlying physical msmq queue we use to represent the party.  2.) set the MessageEventArgs.Cancel argument to True, which will also effectively abort the transaction and roll back the message to the underlying physical msmq queue we use to represent the party. 3.) rollback the ambient transaction like so:

Transaction tx = System.Transactions.Transaction.Current;
if (tx == null) tx.Rollback();

Now...even if you abort the transaction and roll it back, the Party will just try to pick it up again.  How many retries are determined by the retry property values that you configure for the MSMQ network properties at the Topic level, specifically the "Max Retry Cycles", "Receive Retry Count" and "Retry Cycle Delay".

if you want to just handle one message at a time, you can set the network properties of the transport for batch size = 1 (default I think is 100) and max concurrent calls to 1 (default I think is 32).  then in your OnReceive handler code, manage the receipt of the message and then just block processing until you need to handle the next message

Hope this helps

• ▶ Reply