Re: JMS Queue Browsing Receiver

Meeraj,

Thanks for trying that one out.

You were right about using a different provider, I tested the BrowsingMessageReceiver with JORAM and it is working fine. So I'll have to rethink whether to use ActiveMQ or not, but it would be nice to know why it's not working with ActiveMQ. I suppose you would also have to evaluate whether ActiveMQ works with XA transactions as well.

I take your point about the thread local stuff and disposing of the objects that are being created. I'll fix this up, get some tests done and then submit the whole thing to JIRA.

I've had another thought about the sleep/poll routine. Essentially this is what the transport has to do when listening on whatever interface it has. So instead of polling (browsing) the message queue for readiness selection, you might be able to exploit a proprietry messaging provider's API for a non-transactional, non-destructive event notification that could spawn off a worker to consume a message in transaction, in a non-blocking fashion. This would replace the poll/sleep routine with a wait/notify mechanism. I guess this would mean developing a separate transport for this. But isn't that what Mule is all about?

What are your thoughts?

Ben


Ben,

I have tested your BrowsingMessageReceiver with Weblogic JMS provider and seems to be working as expected (dequeueing and processing all the messages instead of stalling after the first). However, with ActiveMQ it appears to be not returning any messages after the first dequeue. I have had a quick look through your receiver. Few minor comments,

1. I don't think you need to bind the browser to the thread local as it is accessed by only the monitor thread.
2. Also, you may not need to start a transaction for browsing.
3. Since you are creating a session and consumer for every dequeue, you may need to make sure they are closed after the transaction commit. You could do this by having them as instance variables in the Work interface implementation and closing them in the release method.

HTH
Meeraj

0x6e6562 wrote:

Andrew,

That's a very good point.

Here's a tiny m2 based project to reproduce the error:

my-app.zip

The main class can be run from eclipse, its called EnqueueingClient.

This starts up activemq and mule.

The eclipse project can be generated by the m2 eclipse plugin.

It initially sends one message to the queue.

You can also send messages via the JMX console for ease of use (its bound to the namespace foo).

Thanks for your help,

Ben

Andrew Perepelytsya wrote:

I know there were issues with queue browsers in ActiveMQ before. Not that it
wasn't fixed by v4 (I just don't know now). Before that it resulted in
messages getting reordered randomly.

The problem will need some investigation. Could you also list the activemq
config file. Generally, the easier you make to reproduce the scenario (test
client, etc.) the higher the chances are you'll get feedback.