Spring Integration
  1. Spring Integration
  2. INT-143

Add correlationId-based request/reply template

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0 M3
    • Component/s: Core
    • Labels:
      None

      Description

      This should probably be implemented as described in the comments for INT-86:

      "...a correlationId-matching client that listens to a shared channel... would probably need to be a handler and selector combination within an endpoint - where the selector knows for which correlationIds it is expecting replies. If more than one such client is listening to the same channel, the correlationId-aware selector would allow for preemptive routing in the dispatching phase."

      Perhaps this can be added to RequestReplyTemplate by means of an alternate constructor that accepts request and reply channels.

        Issue Links

          Activity

          Hide
          Dave Syer added a comment -

          Is there a way to make this generically available as part of a class of SourceAdapters as well (INT-126 provides some context)? I can see this pattern forming in AbstractMessageHandlingSourceAdapter, but it doesn't wait for a correlation-based reply on a control channel, just for the reply-to (using a standard RequestReplyTemplate). Can INT-143 provide a common interface for a RequestReplyOperations for instance, that makes it injectable as a strategy into a SourceAdapter?

          Show
          Dave Syer added a comment - Is there a way to make this generically available as part of a class of SourceAdapters as well ( INT-126 provides some context)? I can see this pattern forming in AbstractMessageHandlingSourceAdapter, but it doesn't wait for a correlation-based reply on a control channel, just for the reply-to (using a standard RequestReplyTemplate). Can INT-143 provide a common interface for a RequestReplyOperations for instance, that makes it injectable as a strategy into a SourceAdapter?
          Hide
          Mark Fisher added a comment -

          The ResponseCorrelator is itself a MessageHandler so it can be registered within an endpoint in order to listen to a 'reply channel'. It matches the correlationId of received messages to any callers that may be waiting for that correlationId (otherwise holds the message in the provided MessageStore - possibly for a limited time based on the store's capacity).

          The getResponse(correlationId, timeout) [or version with no timeout that blocks indefinitely] is called by those waiting for the response messages.

          Perhaps the RequestReplyTemplate can expose another constructor that accepts a ResponseCorrelator instead of relying on an anonymous/temporary queue or callback. We might also want to consider "self-registering" handlers for cases like this. Essentially, a MessageBusAware interface may be useful for these framework components. Thoughts?

          Show
          Mark Fisher added a comment - The ResponseCorrelator is itself a MessageHandler so it can be registered within an endpoint in order to listen to a 'reply channel'. It matches the correlationId of received messages to any callers that may be waiting for that correlationId (otherwise holds the message in the provided MessageStore - possibly for a limited time based on the store's capacity). The getResponse(correlationId, timeout) [or version with no timeout that blocks indefinitely] is called by those waiting for the response messages. Perhaps the RequestReplyTemplate can expose another constructor that accepts a ResponseCorrelator instead of relying on an anonymous/temporary queue or callback. We might also want to consider "self-registering" handlers for cases like this. Essentially, a MessageBusAware interface may be useful for these framework components. Thoughts?
          Hide
          Dave Syer added a comment -

          MessageBusAware would be useful (I think I asked for something like that in INT-125).

          There are sort of 2 orthogonal concerns here - one the choice between anonymous/correlation, and the other the choice between synchronous and asynchronous reply. RequestReplyTemplate could be broken up into two implementations of RequestReplyOperations - one for temporary anonymous, and one for a ResponseCorrelator, both of which could be either synch or asynch depending on whether they were invoked with a callback.

          In any case a *Operations interface will make testing easier.

          Show
          Dave Syer added a comment - MessageBusAware would be useful (I think I asked for something like that in INT-125 ). There are sort of 2 orthogonal concerns here - one the choice between anonymous/correlation, and the other the choice between synchronous and asynchronous reply. RequestReplyTemplate could be broken up into two implementations of RequestReplyOperations - one for temporary anonymous, and one for a ResponseCorrelator, both of which could be either synch or asynch depending on whether they were invoked with a callback. In any case a *Operations interface will make testing easier.
          Hide
          Antonio Mota added a comment -

          Maybe I'm not seeing clear here, but what's the use of a synchronous correlation Id operation? If a request waits for a response there's no need of a correlation id. In my opinion only two operations are needed, anonymous sync and correlation assync.

          Unless one would consider a kind of a "anonymous sync" that on timeout would turn into "correlation assync", meaning,

          • send a request
          • wait for the reply
          • if timed out then return correlationId for later (assync) retrieval

          But that is not a 3rd operation, is only the way you put things together.

          Show
          Antonio Mota added a comment - Maybe I'm not seeing clear here, but what's the use of a synchronous correlation Id operation? If a request waits for a response there's no need of a correlation id. In my opinion only two operations are needed, anonymous sync and correlation assync. Unless one would consider a kind of a "anonymous sync" that on timeout would turn into "correlation assync", meaning, send a request wait for the reply if timed out then return correlationId for later (assync) retrieval But that is not a 3rd operation, is only the way you put things together.
          Hide
          Dave Syer added a comment -

          The requester might be waiting for a response, but he knows that it will come in on a shared channel, and doesn't want to get someone else's. Hence the "synchronous correlator" scenario.

          Show
          Dave Syer added a comment - The requester might be waiting for a response, but he knows that it will come in on a shared channel, and doesn't want to get someone else's. Hence the "synchronous correlator" scenario.

            People

            • Assignee:
              Mark Fisher
              Reporter:
              Mark Fisher
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 3h Original Estimate - 3h
                3h
                Remaining:
                Remaining Estimate - 0d
                0d
                Logged:
                Time Spent - 2d
                2d