Right now, I'm using Sun App Server. I disabled the message listener by setting it to null in the MessageConsumer, and enabled it again using setMessageListener(myOldMessageListener), but after this I don't get any more messages.

5 Answers
5

How about if you don't return from the onMessage() listener method until your system is ready to process messages again? That'll prevent JMS from delivering another message on that consumer.

That's the async equivalent of not calling receive() in a synchronous case.

There's no multi-threading for a given JMS session, so the pipeline of messages is held up until the onMessage() method returns.

I'm not familiar with the implications of dynamically calling setMessageListener(). The javadoc says there's undefined behavior if called "when messages are being consumed by an existing listener or sync consumer". If you're calling from within onMessage(), it sounds like you're hitting that undefined case.

There are start/stop methods at the Connection level, if that's not too coarse-grained for you.

I just noticed that the JMS spec explicitly specifies this serial delivery behavior. It's section 4.4.16 of the JMS 1.0.2 spec. In the past I thought it was just implied by the threading rules.
–
John MNov 9 '09 at 22:24

That looks to me like the messages are being delivered but nothing is happening with them because you have no listener attached. It's been a while since I've done anything with JMS but don't you want to have the message sent to the dead letter queue or something while you fix the system, and then move the messages back onto the original queue once you're ready for processing again?

That might be what happens. Unfortunately, I don't have that control of the jms server, all I can do is to specify a queue to get messages from, no dead letter queue. I guess I could stop the QueueConnection, but that can't be done from the messagelistener thread.
–
davidiMar 9 '09 at 13:16

How come you don't have access to the JMS server. As duffymo has rightly pointed out, its the error queue you want access to. Otherwise you're going to end up replicating behaviour in code that the JMS server provides for you
–
MrWigglesMar 9 '09 at 15:07

I do have that access to the JMS server...in my development environment, but I cannot expect that the users of the application I'm working on (a bridge between two messaging systems) have the same permissions to the JMS server. Is that dead letter queue the usual way to deal with these problems?
–
davidiMar 9 '09 at 20:35

On WebLogic you can set up max retries, an error queue to handle messages that exceed the max retry limit, and other parameters. I'm not certain off the top of my head, but you also might be able to specify a wait period. All this is available to you in the admin console. I'd look at the admin for the JMS provider you've got and see if it can do something similar.