inherent flaw in the inbound-to-outbound channel configuration

[alex.j]

Consider the following spring integration's XML configuration snippet:

<int:inbound-channel-adapter id="inboundChannel" ref="myService" method="myProducerMethod">
<intoller max-messages-per-poll="1" fixed-delay="200"/>
</int:inbound-channel-adapter>
<int:outbound-channel-adapter channel="outboundChannel" ref="myService" method="myConsumerMethod"/>

This works fine, but when application context shuts down the following may occur:
1) Poller within the 'inboundChannel' bean fetches message payload and prepares it for dispatch
2) spring context's shutdown handler disposes 'outboundChannel' bean
3) The spring integration' unicast dispatcher tries to deliver the message prepared at (1) and being unable to do so raises the following exception:

org.springframework.integration.MessageDeliveryExc eption: Dispatcher has no subscribers.
at org.springframework.integration.dispatcher.Unicast ingDispatcher.doDispatch(UnicastingDispatcher.java :108)
at org.springframework.integration.dispatcher.Unicast ingDispatcher.dispatch(UnicastingDispatcher.java:1 01)
... (omitted for clarity).

Please, tell me whether this behavior is WAD or not and if it is I'll raise the appropriate issue with the reproducible sample attached.

P.S.: I've found that the mentioned exception may be suppressed by adding error-channel="nullChannel" attribute to the poller within the inbound-channel-adapter but I don't like this workaround as error suppression looks completely flawed.

[Gary Russell]

Please see this Pull Request https://github.com/SpringSource/spri...ation/pull/403 and its associated JIRA issue.

We have added a method to the IntegrationMBeanExporter that shuts down the schedulers and executors first, in an orderly fashion, allowing any in-flight messages to complete (up to a timeout).

It should solve your problem. It should make it into the upcoming 2.2 milestone 1 release.

[alex.j]

Please see this Pull Request https://github.com/SpringSource/spri...ation/pull/403 and its associated JIRA issue.

We have added a method to the IntegrationMBeanExporter that shuts down the schedulers and executors first, in an orderly fashion, allowing any in-flight messages to complete (up to a timeout).

It should solve your problem. It should make it into the upcoming 2.2 milestone 1 release.

I'll check this, thank you.