Add support for RoutingSlip [INT-267]

[spring-operator]

Marius Bogoevici opened INT-267 and commented

Essentially one should be able to specify the path of a message as it progresses via different channels.

Consider the possibility of the messages specifying this dynamically.

---

Issue Links:

• Document Scatter-Gather, Routing Slip and Idempotent Receiver Support [INT-3538] #7501 Document Scatter-Gather, Routing Slip and Idempotent Receiver Support
  ("is depended on by")

Referenced from: pull request #1280

14 votes, 15 watchers

[spring-operator]

Mark Fisher commented

This and other process-related patterns (Process Manager, Composed Message Processor) might be deferred to 2.0.

[spring-operator]

Mark Fisher commented

I have been experimenting with a global "reply-fowarding" channel to encapsulate the logic that is currently in the AbstractMessageHandler's "resolveReplyChannel()" method (and possibly using the same for error-channel determination).

One advantage of such an approach is that we would have a single isolated strategy for dealing with replies (or output-channel or nullChannel, etc). If we follow that path, we might be able to add "routing slip" or "itinerary" support there as well (e.g. first look for a ROUTING_SLIP header... it could be a Queue or Stack).

[spring-operator]

Mark Fisher commented

I've prototyped a version of this that is based upon a MessageChannel "proxy" implementation that is set as the "replyChannel" in the MessageHeaders. That proxy keeps track of the index (based on an actual send() call to the replyChannel... i.e. at the end of a message flow/pipeline), and then it ultimately (when the routing slip channel names have all been used) sends to the actual replyChannel.

Updating the issue with a target of RC1.

[spring-operator]

Marius Bogoevici commented

I have something very similar locally, and Git makes it fairly easy to share.

One concern I found interesting to address is retry semantics (e.g.making sure that if sending a message to one of the destinations on the RoutingSlip fails, and there is a retry strategy, the retry will send the message to the same destination as before).

[spring-operator]

Mark Fisher commented

moving to 2.1 M1

[spring-operator]

Raman Gupta commented

Marius -- would you be able to share your local implementation of this?

[spring-operator]

Artem Bilan commented

Guys,

Is anybody who is involved in implementation of this issue, or I can boldly take care of it?

Cheers

[spring-operator]

Gary Russell commented

Merged.