Spring Integration
  1. Spring Integration
  2. INT-1770

TCP: Provide Option to Separate Connection Establishment from Message Flow

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.1 M3
    • Component/s: Adapters
    • Labels:
      None
    • Environment:
      Windows XP

      Description

      Summary was: Provide options to configure TCP client to receive data only (without sending any data to server)

        Issue Links

          Activity

          Hide
          Mahendra Korat added a comment -

          Correct description is ==> Provide options for configure TCP client to receive data only (without sending any data to server)

          Show
          Mahendra Korat added a comment - Correct description is ==> Provide options for configure TCP client to receive data only (without sending any data to server)
          Hide
          Mahendra Korat added a comment -

          Is there any progress on this?

          Show
          Mahendra Korat added a comment - Is there any progress on this?
          Hide
          Diego Bravo added a comment -

          The title should be changed for something like "client connect support independent of data".

          I think the best way to implement this would be to allow for a special payload to be sent to the outbound channel adapter (maybe an object of some SI defined class or some special header) which in turn triggers the connection but doesn't attempt to send anything. That way the retry could be controlled from any user defined scheduler. BTW, those "retry" signaling messages should be ignored if the connection is already established.

          Show
          Diego Bravo added a comment - The title should be changed for something like "client connect support independent of data". I think the best way to implement this would be to allow for a special payload to be sent to the outbound channel adapter (maybe an object of some SI defined class or some special header) which in turn triggers the connection but doesn't attempt to send anything. That way the retry could be controlled from any user defined scheduler. BTW, those "retry" signaling messages should be ignored if the connection is already established.
          Hide
          Gary Russell added a comment - - edited

          I am proposing the following (as it would appear in the reference documentation)...

          Inbound Endpoints and Connection Establishment

          The most common use case for inbound endpoints (gateway and channel adapter) is when they act as a server (listen for incoming connections). This is achieved by simply configuring them with a type="server" connection factory. However, there are use cases where the inbound endpoint establishes a connection to a server and then waits for incoming (unsolicited) messages from that server. These may be request/reply scenarios (gateway) or inbound only.

          For a gateway, this can be achieved by configuring the inbound gateway with a type="client" connection factory. For an inbound channel adapter, additional configuration is required because it is also possible to use a client connection factory when an inbound channel adapter is collaborating with an outbound channel adapter (to receive asynchronous replies to messages). To use a client connection factory to establish the connection for an inbound channel adapter, set 'client-mode="true"'.

          Additional attributes on the inbound endpoints to support this functionality are:

          retry-interval - the interval (milliseconds) between connection attempts if a connection fails (default 60,000).
          task-scheduler - provides a thread to be used to open the connection

          The endpoints support 'SmartLifecycle' and auto-start defaults to true. The connection will be attempted/retried only when the endpoint is started. Stopping the endpoint closes the connection and no attempt will be made to re-establish the connection until the endpoint is started again.

          The following <control-bus/> commands are supported:

          @endpointName.start()
          @endpointName.stop()
          @endpointName.retryConnection()

          retryConnection() provides a mechanism for the application to control when connections are attempted, this can be in addition to the retry schedule (or can completely replace it by setting the retry interval to -1).

          single-use connections are not supported when an inbound adapter establishes the connection.

          Show
          Gary Russell added a comment - - edited I am proposing the following (as it would appear in the reference documentation)... Inbound Endpoints and Connection Establishment The most common use case for inbound endpoints (gateway and channel adapter) is when they act as a server (listen for incoming connections). This is achieved by simply configuring them with a type="server" connection factory. However, there are use cases where the inbound endpoint establishes a connection to a server and then waits for incoming (unsolicited) messages from that server. These may be request/reply scenarios (gateway) or inbound only. For a gateway, this can be achieved by configuring the inbound gateway with a type="client" connection factory. For an inbound channel adapter, additional configuration is required because it is also possible to use a client connection factory when an inbound channel adapter is collaborating with an outbound channel adapter (to receive asynchronous replies to messages). To use a client connection factory to establish the connection for an inbound channel adapter, set 'client-mode="true"'. Additional attributes on the inbound endpoints to support this functionality are: retry-interval - the interval (milliseconds) between connection attempts if a connection fails (default 60,000). task-scheduler - provides a thread to be used to open the connection The endpoints support 'SmartLifecycle' and auto-start defaults to true. The connection will be attempted/retried only when the endpoint is started. Stopping the endpoint closes the connection and no attempt will be made to re-establish the connection until the endpoint is started again. The following <control-bus/> commands are supported: @endpointName.start() @endpointName.stop() @endpointName.retryConnection() retryConnection() provides a mechanism for the application to control when connections are attempted, this can be in addition to the retry schedule (or can completely replace it by setting the retry interval to -1). single-use connections are not supported when an inbound adapter establishes the connection.
          Hide
          Gary Russell added a comment -

          Also see http://forum.springsource.org/showthread.php?113665-Retrying-TCP-connection

          'client-mode' will also be supported on outbound endpoints.

          Connection establishment for outbound endpoints is currently driven by the first message sent by the endpoint. To establish (non single-use) connections on outbound adapters, the above attributes/operations will be supported if 'client-mode="true"'.

          Show
          Gary Russell added a comment - Also see http://forum.springsource.org/showthread.php?113665-Retrying-TCP-connection 'client-mode' will also be supported on outbound endpoints. Connection establishment for outbound endpoints is currently driven by the first message sent by the endpoint. To establish (non single-use) connections on outbound adapters, the above attributes/operations will be supported if 'client-mode="true"'.
          Hide
          Gary Russell added a comment -

          Pull Request here https://github.com/SpringSource/spring-integration/pull/127

          You can build from my branch if you want to give it a spin before it gets into master.

          Show
          Gary Russell added a comment - Pull Request here https://github.com/SpringSource/spring-integration/pull/127 You can build from my branch if you want to give it a spin before it gets into master.

            People

            • Assignee:
              Gary Russell
              Reporter:
              Mahendra Korat
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: