Event receive ActiveMQ messages only one message per second?
We have built an application framework based on ActiveMQ.
We can send and receive messages just fine, and for the most part everything is pretty fast and normal.
However, we noticed that if we send a batch of messages "at once", say 5000 messages - that ActiveMQ will receive messages in a third-party application on the other end rather quickly and that this application will process quite quickly, and that it will return responses as quickly broker in, say, a minute.
But for some reason, our VB.NET EXE, which triggered the messages in the first place, only handles the returned messages it receives randomly, sometimes doing about one second, sometimes taking breaks for an hour or so, and then going back to one per second.
Origin (VB.NET EXE which we manage)
-> Broker (which we manage)
-> (3rd party app)
-> back to the same broker
-> back to the origin app.
The receiver is waiting for a MessageListener event from C # code loaded from ActiveMQ, maybe 9 months ago:
Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
Member of: NMS
I think what happens is that the MessageListener only gives us one message (NMS.IMessage) to chew on, and so that we process.
Can you say "In the MessageListener event, see if there are other messages in the queue right now and all of them"?
source to share
It turns out we think we know a little more about what that means.
When our VB.NET WinForms application using the ActiveMQ DLL ends up crashing, which it tends to do several times a week, we have a watchdog program that uses the Winternals pslist and pskill utilities to collect zombies and then starts a new one client connection.
When this happens, using jconsole to parse the broker shows us that the zombie session is still logged, as well as a new new client.
My theory right now is that when AMQ sees both sessions, it tries to start propagating messages to both sessions in a round-robin fashion. AMQ tries to send a message to a zombie that doesn't respond. After some time (perhaps one second) AMQ gives up and moves on to the next session on the list, a new new client.
At some point, the broker or TCP stack probably notices that the zombie did not support his TCP connection, and he refuses; then the work will return to normal operation.
So the question is, how do I write an ActiveMQ client that a) doesn't die, or b) cleverly dies, terminating its session in the process?
Edit: Switching to the next version of ActiveMQ solved it. We also had one application doing send and receive, but it was not thread safe - so if it was received when it tried to send it crashed. We rewrote it as two console applications, one of which sent the data and the one that received the data. No more crashes. Also the older version of ActiveMQ that we were using at the time didn't handle gracefully, upgrading to 4.x allowed that.
source to share
I suggest reporting this to the "User Forum" and also raising it as it sounds like it might be an issue with the NMS client code and all NMS developers are on this list and can answer
source to share