Delayer message store questions

Hi,

I was looking at the delayer today and trying to use this as part of some error handling we are putting in place for our application and had a few questions:

• If the delayer is configured with a persistent message store and there are pending messages in the store when the application is shut down they don't seem to ever be processed with the application is restarted. Other than saving on potential memory usage, it doesn't seem like the message store is buying us much here. How do people handle this type of scenario -- should we just write a bean that queries the DB and resubmits these to the input channel for the delayer on application startup?
  
• I can't seem to find any information regarding tying a transaction to the scheduler thread the delayer is using. For example, if there is an error sending the message to the output channel of the delayer can I tie this processing to the transaction manger of the delayer message store so I am guaranteed not to lose the message (i.e. if I am sending from a delayer to a JMS destination that happened to be down for some reason)?

Thanks,
Ryan

Your first bullet is addressed by the upcoming 2.2 release, and is included in the milestone released yesterday.

http://www.springsource.org/node/3586

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

However, it doesn't support transactions on the scheduler thread, yet; please go ahead and open a JIRA issue https://jira.springsource.org/browse/INT

When rescheduling messages after startup, we use the original arrival time of the message, and the delay, to determine the release time (if not past due, in which case the message is released immediately).

Adding transactions raises an interesting issue - when should the release be scheduled? By definition, the message's release time is already past due; does the message get a new delay cycle after the transaction rolled back, or do we reschedule immediately? What if the delay was based on a Date header (specific release time)? How do we reschedule that?

Hello

I've raised an JIRA tickek about transaction support for the Delayer: https://jira.springsource.org/browse/INT-2649
Right now we have scheduled task in the separate thread for each delayed messages, so it will be good point to wrap this thread with transaction, because following the delayer message-flow may be direct and will be at the same thread.

About last Gary's thoughts:

Quote:

---

after the transaction rolled back

---

I think we should follow here with RetryInterceptor strategy: https://jira.springsource.org/browse/INT-343.
Release Mesasge -> handle -> roll back -> retry.

Ryan, try to use the latest release 2.2.0.M3 and let us know how Delayer works. We will be glad to hear any feadbacks ;)
Order to make your life easier I'm giving you several links about changes for Delayer in the Spring Integration 2.2:
https://github.com/SpringSource/spri...igration-Guide
http://static.springsource.org/sprin...r.html#delayer

Also keep in mind, if you use JDBC MS: in the 2.2 DB shema was changed. Now it has three tables.

Best regards,
Artem Bilan

P.S. @Gary, I think we should add some note about JDBC-MS changes in the Migration Guide.