JMX - Problem in controlling inbound channel adapters

[plecesne]

Hi,

To start and stop my flows, I used to start and stop the whole context.
However, following the discussion http://forum.springsource.org/showthread.php?t=95050 , I wanted to try to stop my flow by stopping the inbound channel adapter through JMX.

I encountered two issues:

1. It happens, that the <int-jms:message-driven-channel-adapter> does not seem to be exposed as a MessageSource (I checked from the jconsole).
Is there any reason why it isn't exposed?

2. So I tried to use a <int-jms:inbound-channel-adapter>. This one is exposed as a MessageSource, but then, stopping the endpoint doesn't actually stop it from reading from the JMS Destination ; it then just loops and keeps trying until the endpoint is started again ("looping" maybe because of my transactional context, though I'm not sure it's related).
Is there any reason why it still keeps reading on the JMS Destination and loops even though the endpoint is stopped?

Thank you,

-- Pierre

[Dave Syer]

The message driven adapter is not a MessageSource so that explains why it is not exposed automatically. You could use normal Spring JMX to expose the MessageListenerContainer inside it, and probably at some point Spring JMS will make that automatic, but it isn't right now. I would do that, rather than use the polling version anyway.

Not sure why the polling version wouldn't stop polling (I assume you called stop() on it?). It should work the same as any endpoint that contains a MessageSource - i.e. shutdown the poller and cancel any outstanding tasks. This isn't always what you want for a graceful shutdown, but for a transactional message source it should be fine. Can you raise a JIRA?

[plecesne]

Hi, thank you for your answer.
Yes, I indeed called stop(). I won't have the opportunity to raise a JIRA for the next two weeks, but as soon as i can, I will

[Mark Fisher]

The reason that the Message-driven adapter does not implement MessageSource is that it is not itself "pollable". The MessageSource interface is intended for those endpoints where a receive() call that returns a Message would apply. With the Message-driven JMS adapter, however, it's just managing a DefaultMessageListenerContainer instance behind the scenes, and that container is pushing any Messages it receives directly to a Message channel (hence no "polling" from the perspective of the Spring Integration application components).

As far as the stop() method is concerned, that does indeed delegate to the stop() method of that underlying DefaultMessageListenerContainer instance - so it *should* stop the flow of incoming JMS Messages. One thing to keep in mind though is that the DefaultMessageListenerContainer does not stop immediately by default. It will complete the processing of any Messages that are in-flight. Perhaps that is the behavior you are witnessing? If not, we would definitely appreciate any more detail you can provide.

HTH,
Mark

[plecesne]

Hi,

I couldn't reproduce the issue on 2)... Maybe I did something wrong the first time and thus won't investigate further.

--
Regarding 1), I exposed my DefaultMessageListenerContainer and I now have the following behaviour:
A call of stop() or shutdown() works well, as no message is processed, but the next message arriving on the queue is consumed anyway (although neither processed nor acknowledged, so not lost).
This has two consequences:

• As long as the JVM is still running, the message can't be seen on the queue (because currently awaiting to be acknowledged or rollbacked).
• If the container is started again, the received message has the "$jms_redelivered" header set to true. This should not be the case since the message arrived after the container has been shutdown.

Would somebody know why Spring JMS has such behviour?
And any idea how to really prevent the JMS consumer from reading on the queue (to avoid the two consequences mentionned above).

Thank you,

Pierre

[plecesne]

Does that ring a bell to somebody?
Should I raise this question somewhere else?
Thanks !

[osgiliath]

Hi,

I have the same issue as above...
I have a JMS inbound adapter with poller mode (because I want to use max-messages-per-poll property).

And when I call stop method through a control bus :
- it works fine when I'm using Apache ActiveMQ
- it doesn't work when I'm using IBM Websphere MQ

Any idea ?
Plecesne, did you get this issue revoled ?

Thanks a lot !
Cheers

[edit] using the 2.0.3 spring integration version.

[osgiliath]

I was able to have a workaround on this.

I had explicitly created and set a JmsTemplate with a receiveTimeout property...
I don't know why the receive-timeout of the jms-inbound-adapter is not set properly...

Thanks anywway.

[Gary Russell]

What do you mean by "properly"?

What version are you using?

receive-timeout (default infinity) was added to the adapter in 2.0.3.

https://jira.springsource.org/browse/INT-1793

[osgiliath]

Still using 2.0.3.

Actually, i've set only receive-timeout on the poller initially .. and I was with a previous version of SI before... so that's why I didn't know about the property receive-timeout on the adapter.
So it's working fine when putting the property on adapter.

But i'm a bit confused now about to put receive-timeout also on the poller...
Here is my config

<jms:inbound-channel-adapter id="inboundAdapterTest" destination="queue.in" auto-startup="false" connection-factory="connectionFactory" receive-timeout="5000">
<poller fixed-delay="20000" max-messages-per-poll="3">
<transactional transaction-manager="txManager" />
</poller>
</jms:inbound-channel-adapter>

Thank you.