Announcement Announcement Module
No announcement yet.
Graceful stopping of Inbound Channel Adapter Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Graceful stopping of Inbound Channel Adapter


    I have been looking for suggestions to implement a graceful shutdown of an inbound channel adapter (file). Have come across some earlier Jira issues on similar topics, but could not find any concrete solution yet.

    My SI implementation is a simple flow :

    - with an inbound channel adapter and a synchronous processing of the received message with mostly Direct Channels.

    - after all the processing is done the message is delivered to a QueueChannel with queue capacity 1.

    - the final endpoint is a service-activator/gateway which polls the queue channel at regular intervals and picks up any message from the final Queue Channel.

    Now I need to implement a shutdown process for the inbound channel adapter, and make sure that the last message is processed before the actual stop(). Obviously the current SI implementation is sending the last message to the exception processing (as expected).

    Please feel free to ask for any further clarifications.

    Any suggestions will be highly appreciated.


    - Sujit

  • #2
    Hi SujitB,

    Shutting down the channel adapter is not too complicated as you can call stop() on it.

    ((AbstractEndpoint) context.getBean("myInboundChannelAdapter")).stop()
    However, I'm not sure if the channel adapter can know by itself if there are still messages to process.
    If I were you, I would implement another little process which contains the "intelligence" of whether to stop or not the channel adapter. This could be for example a wiretap which decides, in case no message was received for 60 seconds, to shutdown the channel adapter.

    There may be better ways to do this.
    Hope this helps,



    • #3
      ((AbstractEndpoint) context.getBean("myInboundChannelAdapter")).stop()
      Just for fun; how would you do this in a clustered environment?


      • #4
        One thing that might be interesting is to use our new JMX support for actually managing the component lifecycle. I'll see if I can get Dave Syer (whose the primary contributor on that front) to comment on how clustering might factor into the picture.


        • #5
          That would be great. I'm also very interested in doing such things.


          • #6
            JMX and the ControlBus seem like the right solution here (and would provide an answer to the side issue of cluster support, provided the JMX client was cluster aware, e.g. SpringSource HQ).

            The current support in the JMX module only exposes MessageChannels and MessageHandlers (and their endpoints), and you could do something with that, but not prevent new messages coming in from the adapter while you shutdown the downstream endpoints. I'd certainly be open to the idea of extending JMX control to MessageSources and their polling endpoints. Raise a JIRA (quickly) if you want it in 2.0.


            • #7