CODEWITHSUNDEEP
springspring-integration
levant pied
levant pied

Reputation: 4501

Spring integration acknowledge message processing back to previous service

In Spring Integration, I have a chain of services, like this:

message -> A -> B -> C -> D -> ... -> output

This works fine. I want to make each of the services asynchronous and to make them pessimistic. Each of them will get a message, process it and send it to the next service in chain. However, it will not wait till the whole chain finishes. It will continue processing the next message and so on. Standard async here.

However, let's say service B is slower than A and that it accumulates 10k messages in its inbound channel queue and at that time the system crashes. I want to be able to restore the system by figuring out where I left and re-processing the messages. For that reason, I want each of the services to know which of the messages it processed was successfully consumed by the following service. The difference between sent vs. processed.

My idea is to do it similar to this (fancy ascii):

-> A --> B -> C -> ...
   ^     |
   | ack |
   \-----/

That is, A will send to B, B will process and when it is done successfully it will send an ack to A. A will then remove that particular message from the store, so that the next time it runs, it will not re-process it. I thought I would just put a splitter after B that will call a different method on service A (i.e. ackProcessed).

Is this how it should be done in SI or is there another way I'm missing? I'm primarily asking for a confirmation I'm not missing something supported out-of-the-box or something that will not force me to create a splitter after each of the services.

Upvotes: 1

Views: 565

Answers (1)

Gary Russell
Gary Russell

Reputation: 174739

It wouldn't be a splitter; more likely a pub-sub channel and the ack would probably want to go to a different method in A (i.e. a different service-activator that references the same bean, different method; and the methods share some state).

An easier solution would be to use a persistent message channel (e.g. JMS, RabbitMQ, or a message-store-backed QueueChannel). That way the framework will take care of everything for you.

Upvotes: 1

Related Questions