Support rescheduling of release tasks for a persistent MessageStore-backed DelayHandler upon restart [INT-1132]

[spring-operator]

Mark Fisher opened INT-1132 and commented

See the comments in #4751 for the details.

---

Issue Links:

• Document delayer's changes from Spring Integration 2.2 [INT-2623] #6599 Document delayer's changes from Spring Integration 2.2
  ("is depended on by")

• Add support for Control Bus & JMX to DelayerHandler to allow control rescheduling at runtime [INT-2622] #6598 Add support for Control Bus & JMX to DelayerHandler to allow control rescheduling at runtime
  ("is depended on by")

• Consider improving message polling in JdbcMessageStore [INT-2200] #6182 Consider improving message polling in JdbcMessageStore

• DelayerHandlerRescheduleIntegrationTests Fails on OSX [INT-2640] #6614 DelayerHandlerRescheduleIntegrationTests Fails on OSX

• Add support for a MessageStore on the DelayHandler [INT-737] #4751 Add support for a MessageStore on the DelayHandler

1 votes, 2 watchers

[spring-operator]

Mark Fisher commented

moving to RC1

[spring-operator]

Mark Fisher commented

Oleg, I'm not sure whether we need to add this functionality, but I'll assign it to you for now in case you want to experiment.

[spring-operator]

Mark Fisher commented

It seems there are 2 options for this: 1) require that the DelayHandler has exclusive access to its MessageStore instance (so it can get all Messages from it... although we don't have an iterator or getAll method on MessageStore in the first place) or 2) change the dependency to MessageGroupStore and assign a "groupId" for all Messages added to the store by a given delayer. Option #1 seems inplausible, but Option #2 seems like an odd use of "group". Thoughts?

[spring-operator]

Mark Fisher commented

I'm thinking about this some more, and it does seem odd that a delayer might have a delay of 10 minutes so that a Message might have been delayed 9 minutes already, but after a restart all Messages would be delayed for 10 minutes - even though our example Message should really only have 1 minute remaining (and that alone is odd considering it's as if time were "frozen" while the system was down).

However, the alternative if we do not implement this feature, is that all of the Messages that had been delayed upon shutdown/crash would simply be lost upon restart.

[spring-operator]

Oleg Zhurakousky commented

Ok, now since i have a better understanding of this issue #2 actually seems pretty reasonable as each DelayHandler would essentially manage its own group within the group store which isn't that bad.
However, what we will loose is the flexibility of using multiple implementations of MessageStore by multiple DelayHandlers (e.g., cache and RDBMS). They would all depend on the single implementation of the MGS. Would that be an issue?

[spring-operator]

Oleg Zhurakousky commented

Sorry, now all these comments are out of order ;) So this is to your last comment.
I think the problem you are describing could be solved if upon the restart of the system DelayHandler would check the timestamp of all the Messages and compare it to its delay settings and current time. This way if an example Message has already been delayed for 9 min before and the system was down for an hour, upon restart our example Message will be release right away.

[spring-operator]

Oleg Zhurakousky commented

Moving it to 2.1 as it needs more discussions

[spring-operator]

Artem Bilan commented

Hello, colleagues
I need this solution right now.
I think, I'll try to implement it myself

[spring-operator]

Artem Bilan commented

Implementation of Delayer rescheduling depends on adding support of Rerty Interceptor.

[spring-operator]

Artem Bilan commented

I want to revisit this feature as it is still important for me.
I've investigeted RetryPolicy in the Spring Batch and also in the Apache Camel and now I don't understand how it can help here.
That pattern is based on +Exception resulution+, and rescheduling should work on system restart...
It's normal message flow operation: no exceptions, no rollbacks.
I suggest to convert delayer's messages to group based on delayer's id and to run rescheduling on component's startup.
It's simple way.
Another solution may be based on some ReschedulingStategy. Which we can use in many other stateful components: aggregator, scatter-gather, claim-check-out (?) etc.

[spring-operator]

Mark Fisher commented

Moving to the backlog. This can be moved back to a specific release if it's going to be available.

[spring-operator]

Artem Bilan commented

Mark, no problem! I have some thoughts, because I strictly need this solution (my customer need ;-))
But it depends on important changes in the MessageGroupStore
Please, look at my comment in the #6182

Thanks a lot

[spring-operator]

Artem Bilan commented

Issued PR: #457

[spring-operator]

Oleg Zhurakousky commented

Moving it to M3 while keeping PR active

[spring-operator]

Artem Bilan commented

Fresh PR: #488