Spring Integration
  1. Spring Integration
  2. INT-86

Add synchronous, blocking channel publisher/requestor

    Details

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

      Description

      This requestor should enable sending a message to a channel and waiting for a reply message on either a temporary replyChannel (backed by a synchronous queue) - or waiting on a shared channel and using the message's correlationId to match. The timeout value for waiting on a reply should be configurable.

      While implementing this, a number of other refactorings may be necessary, such as 1) SimpleChannel should support a 0-sized capacity for direct handoff, and 2) the message should support actual reply channel references in addition to replyChannelName.

        Activity

        Hide
        Mark Fisher added a comment -

        Added org.springframework.integration.channel.RequestReplyTemplate. This acts as either a synchronous client for asynchronous requests (blocking on a private synchronous channel provided as the 'returnAddress') or as an asynchronous client that passes a replyHandler callback.

        If there is a need for a correlationId-matching client that listens to a shared channel, then it should be a separate implementation. In fact it 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. We should consider this for M3.

        Show
        Mark Fisher added a comment - Added org.springframework.integration.channel.RequestReplyTemplate. This acts as either a synchronous client for asynchronous requests (blocking on a private synchronous channel provided as the 'returnAddress') or as an asynchronous client that passes a replyHandler callback. If there is a need for a correlationId-matching client that listens to a shared channel, then it should be a separate implementation. In fact it 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. We should consider this for M3.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0.75d
              0.75d
              Remaining:
              Time Spent - 0.5d Remaining Estimate - 0.25d
              0.25d
              Logged:
              Time Spent - 0.5d Remaining Estimate - 0.25d
              0.5d