Details

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

      Description

      When we can't use UDP at all it would be nice to use IP/port-list for sending message to several receivers - TCP multicast.
      It can be something like <ip:multicast-tcp-outbound-channel-adapter/> which gets List<Connection> from clientConnectionFactory. I don't see any reason to have here gateway... Also there must be some flag async = true/false, when we decide to send message to the connections one by one, or use async task executor.
      When we implement RetryInterceptor it may be good to use here AggregateMessageDeliveryException, which contais list with MessageDeliveryException each of which has undeliveredMessage. This ability may be used inside RetryPolicy where we make decision about failed hosts.

        Issue Links

          Activity

          Hide
          Gary Russell added a comment -

          The basic use case can be achieved with a <recipient-list-router/>, with sync/async being controlled by downstrean channel topology.

          The second part (AggregatedMessageDeliveryException) sounds like a feature enhancement to the <recipient-list-router/>; instead of ignore-send-failures have failures-channel that gets an ErrorMessage.

          I don't think we want the retry interceptor to get involved with partial retries; you could put a retry interceptor on each subscriber.

          Bottom line, I think we should keep these concerns separate from TCP itself. I think that handling these conditions in an RLR would make the feature available for a wider audience rather than just TCP.

          Show
          Gary Russell added a comment - The basic use case can be achieved with a <recipient-list-router/>, with sync/async being controlled by downstrean channel topology. The second part (AggregatedMessageDeliveryException) sounds like a feature enhancement to the <recipient-list-router/>; instead of ignore-send-failures have failures-channel that gets an ErrorMessage. I don't think we want the retry interceptor to get involved with partial retries; you could put a retry interceptor on each subscriber. Bottom line, I think we should keep these concerns separate from TCP itself. I think that handling these conditions in an RLR would make the feature available for a wider audience rather than just TCP.
          Hide
          Artem Bilan added a comment -

          OK, I agree about

          keep these concerns separate from TCP itself

          But it still produces an issue about configuration of several TCP-components for each HOST & PORT: we can't have something like this in Properties:

          multicust.tcp.hosts=host1:port1,host2:port2,host3:port3
          

          Or I want to use here some properties of Application Servers: as JBOSS group, or WAS node agent.
          A workaround: configure those components programmatically in a cycle.

          Show
          Artem Bilan added a comment - OK, I agree about keep these concerns separate from TCP itself But it still produces an issue about configuration of several TCP-components for each HOST & PORT: we can't have something like this in Properties: multicust.tcp.hosts=host1:port1,host2:port2,host3:port3 Or I want to use here some properties of Application Servers: as JBOSS group, or WAS node agent. A workaround: configure those components programmatically in a cycle.

            People

            • Assignee:
              Gary Russell
              Reporter:
              Artem Bilan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: