Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 4.1 RC1
    • Component/s: Core
    • Labels:

      Description

      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

          Activity

          Hide
          mark.fisher Mark Fisher added a comment - - edited

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

          Show
          mark.fisher Mark Fisher added a comment - - edited This and other process-related patterns (Process Manager, Composed Message Processor) might be deferred to 2.0.
          Hide
          mark.fisher Mark Fisher added a comment -

          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).

          Show
          mark.fisher Mark Fisher added a comment - 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).
          Hide
          mark.fisher Mark Fisher added a comment -

          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.

          Show
          mark.fisher Mark Fisher added a comment - 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.
          Hide
          mbogoevici Marius Bogoevici added a comment - - edited

          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).

          Show
          mbogoevici Marius Bogoevici added a comment - - edited 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).
          Hide
          mark.fisher Mark Fisher added a comment -

          moving to 2.1 M1

          Show
          mark.fisher Mark Fisher added a comment - moving to 2.1 M1
          Hide
          raman Raman Gupta added a comment -

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

          Show
          raman Raman Gupta added a comment - Marius – would you be able to share your local implementation of this?
          Hide
          abilan Artem Bilan added a comment -

          Guys,

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

          Cheers

          Show
          abilan Artem Bilan added a comment - Guys, Is anybody who is involved in implementation of this issue, or I can boldly take care of it? Cheers
          Hide
          grussell Gary Russell added a comment -

          Merged.

          Show
          grussell Gary Russell added a comment - Merged.

            People

            • Assignee:
              abilan Artem Bilan
              Reporter:
              mbogoevici Marius Bogoevici
            • Votes:
              14 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: