Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: General Backlog
    • Component/s: Core
    • Labels:
      None

      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.

        Activity

        Hide
        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 added a comment - - edited This and other process-related patterns (Process Manager, Composed Message Processor) might be deferred to 2.0.
        Hide
        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 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 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 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
        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
        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 added a comment -

        moving to 2.1 M1

        Show
        Mark Fisher added a comment - moving to 2.1 M1
        Hide
        Raman Gupta added a comment -

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

        Show
        Raman Gupta added a comment - Marius – would you be able to share your local implementation of this?
        Hide
        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
        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

          People

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

            Dates

            • Created:
              Updated: