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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…