Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Turns out, we think we know a bit more now what this is about.</p> <p>When our VB.NET WinForms app that uses the ActiveMQ DLL eventually crashes, which it tends to do a few times a week, we have a watchdog program that uses the Winternals pslist and pskill utilities to reap the zombie, and then start a new client connection.</p> <p>When this happens, using jconsole to analyze the broker shows us that the zombie's session is still registered, and so is the fresh new client.</p> <p>My theory right now is that when AMQ sees both sessions, it tries to start distributing messages to both sessions round-robin style. AMQ tries to send the message to the zombie, which does not respond. After a certain amount of time (one second perhaps) AMQ gives up and goes to the next session in the list, the new fresh client.</p> <p>At some point, the broker or TCP stack probably notices that the zombie has not kept it's TCP connection active and it gives up; then operation goes back to normal.</p> <p>So the question becomes, how to write an ActiveMQ client that a) does not die or b) dies gracefully, shutting down it's session in the process?</p> <p>Edit: upgrading to the next version of ActiveMQ solved this. Also we had a single app doing the sending and receiving, but it was not threadsafe - so if it received while it was trying to send this caused the crashes. We re-wrote it as two console apps, one that sent data and one that received data. No more crashes. Also the older version of ActiveMQ we were using at the time didn't handle crashes gracefully, upgrading to 4.x solved that.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload