Async message delivery problem

[s.goetz]

Hello all,

nearly two years ago we started developing our new access control system using hornetQ as major data exchange platform to synchronize the parts of the application. Let me say that I never had any regrets afterwards since this software is really great. Unfortunately I am not able to solve the following issue on my own as it seems:

We use hornetQ as message outbox for communication to our devices. Since there can be many devices I chose to use a thread pool in order to look for messages for a controller. For this purpose I use asynchronous message reception via the MessageHandler interface. When I receive a message for a device I deregister the message handler for this queues consumer so no more messages come in for the device. After the device has acknowledged the message (which takes another road via TCP) I acknowledge the message to the queue and re-register the message handler on the consumer. This works like a charm and with a consumer window size of 0 and a grouping header property I can even manage to have all the messages for one device received by the same consumer sequentially.

So far, so good. Occasionally I have now the behavior that though the message handler is registered and there are messages in the queue, no messages are delivered by the server. If I then issue the resume() method via the JMX console the messages get delivered again. The queue is NOT stated as paused in the JMX console prior to issueing the resume call. So I think the resume call internally triggeres some restart on the client sessions.

For incoming messages I also use a thread pool with a fixed size. But here the threads are receiving in blocking mode via receive(). I never had any trouble with the incoming side. Only the asynchronous outgoing side has the problem.

I this a known bug or am I working with an anit-pattern here? I cannot provide a test case since this happens occasionally only and I haven't yet figured out, what may be the cause.

Any help is appreciated. By the way I am using the 2.2.14 release.

Regards,

Sebastian

[jbertram]

This doesn't sound like any bug I can remember.  That said, 2.2.14 is quite old at this point.  I recommend you move to 2.4.0.Final.  If you can reproduce this problem there then I'd be willing to investigate further.

You might also try just invoking stop() and start() on the ClientSession associated with the MessageHandler rather than registering and unregistering the handler itself.

[s.goetz]

Hello Justin,

Justin Bertram schrieb:

You might also try just invoking stop() and start() on the ClientSession associated with the MessageHandler rather than registering and unregistering the handler itself.

I wasn't aware of that option at all. Sounds like a good alternative. I will try this and give some feed back.

I know that 2.2.14 is about two years old be now. Also thought of trying to upgrade to 2.4.0.final. I am going to check this option also.