Spring Integration destroy-methods

Hey Guys,

I am working on an app that strings together a variety of components using spring integration. My issue is, when the app is gracefully shutting down, I want to send a message through the system to kind of "flush" things through, in a sense. It's not exactly a flush, but it does what a flush would do and more. Anyway, when the shutdown message is received and spring starts "destroy'ing" it's beans, the message doesn't flow through as I want it to. This, I believe, is because the beans are being destroyed at the same time. Can anyone offer insight as to how to go about implementing this functionality that I am describing? If anyone has any more specific questions, I will be happy to explain things in as much detail as I am allowed.

Thanks,
Mark

What is the starting endpoint in your application?

One common pattern is to use the <control-bus/> to send a stop() message to the inbound adapter and then wait for any in-flight messages to complete.

Yeah, I think describing your use case in more details would help. As Gary suggested sending stop message via the ControlBus is one way of 'cleaning up'. There is also ApplicationContextEvent(s) that you can listen to when shutting down your application.

Hey Guys,

Thanks for the responses. I am currently using the application context events to trigger the behavior I desire, but that isn't working very well.

A little more detail about my application:

We have a listener/receiver that accepts socket connections and spawns "clients" to handle those socket connections as we see them. This allows for multiple clients to be reading at any given time. These clients accept data and, after the data has been verified to be formatted correctly, etc... a gateway will "receive" the object so it can start being passed through the spring integration channels.

When a client stops seeing data, it produces a "flag" to signal that the processing is done for that data. We do this because a single connection can produce 1...n objects that are all related and we eventually will need to tell a follow on system that this set of data has ended.

Anyway, after all kinds of fun processing that is not important to this problem, the data will then be sent via socket connection to a follow-on system. Once again, there can be multiple "senders" doing the sending to speed things up.

The issue we are having is, when the application is shutting down, if some of the data hasn't been completely processed yet, it will simply be forgotten. So, we need to send the ending "flag" and wait for the data to finish processing. After that has been done, we then exit.

Both the receiver and the sender have destroy-methods along with a variety of other components as well. Over the past few days I've been toying with ways to send this ending flag, but have been unsuccessful.

My apologies if this message is somewhat fragmented. I am literally just stream-of-consciousness typing as I have a million things going on. I'll begin looking into the control-bus pattern to see if that is a possible solution. Thanks again for any help you can offer.

The way I see it asort of goes along with what Gary suggested. Your system must only be stopped based on knowledge that the last message have been processed and no more messages are coming which could be accomplished by:
1. Shutting down the gateway (entry point to the system). This will ensure that no more messages are coming
2. Notifying the process responsible for shutting down the system that it can in fact shut it down.

The first one is easy. My question is about the second one. How would you know that the last message have been processed? Is there an event that could be generated?