Demystifying Durable and Transactional enterprise deployments

Comment

Comment by Brandon on February 11, 2009 at 12:31pm

The Msmq adapter will no longer turn off due to errors starting from build 2.0.1176.0025

Comment by CM on February 10, 2009 at 6:37am

Hi Frosty,


As I indicated in the post, for remote Neuron clients you need the MSMQ channel + server cache mode when using MSMQ 3.0. Using this combination in conjunction with a local persistent store can be used to develop a store and forward scenario with Neuron.


However, the Party classes (Subscriber, Publisher) were not designed for use in IIS. They are doing a lot in the background in order to receive messages on Topics and also to download their pipelines and keep them up to date.

In this case, the choice of a service that monitors the queues and uses a transactional write to a queue on the Neuron server which would then pick up the message via the MSMQ adapter is better or reading the message from the local persistent store in the service and forwarding it via the Neuron API works as well.

We will definitely look into the MSMQ Adapter behavior you're describing,

Finally, thanks for posting the first comment in neuronesb.com history!

--CM

Comment by Frosty on February 9, 2009 at 9:11pm

Guaranteed deliver / zero message loss can indeed be important, and in our environment is one that we depend on. Your above scenario hold true, given that there has been no network outage between the remote client and the Neuron server. In our scenario, which is primarily integration based, we must still guarantee message delivery (even in a very limited disconnected state), This message pattern is one way (an event) and needs to be as undisruptive as possible to the application generating the event. Our solution was to use a store and forward pattern, initially writing the message to a local (to the publishing application) MSMQ and then asynchronously sending the message to Neuron either in process or using an out of process service to send then message.

When using the in process solution, we have found that Neuron (or more specifically the Neuron API) appears to hang on to resources (maybe due to garbage collection or something in IIS... we have not been able to completely determine that exact cause) and does not allow us to immediately deploy an update to the publishing application, even when restarting the application pool. Restarting IIS is not an option.

This leads us to solution B, out of process sending messages using the Neuron API. We monitor the local queue(s) and when a message is received, the service application will dequeue the message and forward on to Neuron. This has its own set of flaws, but appears to make the architect of this application happy. I see more problems down the road, but for now this works.

We originally thought we could solve this using an MSMQ adapter, but alas, if the Neuron server and the remote machine hosting the publishing application are disconnected for more than a couple of minutes, then the Neuron MSMQ adapter gives up and will not try to connect again unless the ESB service is restarted. We may revisit this strategy and write our own version of an MSMQ adapter that degrades a little more gracefully.

Did I miss an obvious solution or given our requirement of 100% (not 99.5%) guaranteed message (event) delivery, did I take a reasonable approach?