Announcement Announcement Module
Collapse
No announcement yet.
TCP server, service activator, async messages Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP server, service activator, async messages

    Hi,
    I am using a simple TCP inbound gateway with a server connectionfactory to act as a TCP server, see config below.
    Depending on the message received, the server should either send back a message immediately, or start up a scheduled task (or similar) that sends messages without requests on a regular basis.

    Synchronous works fine if the handleMessage method provides a return parameter (like a String or so), but I can't seem to be able to send a message directly to the replyChannel without getting a
    org.springframework.integration.support.channel.Ch annelResolutionException: no output-channel or replyChannel header available
    Probably missing something obvious - but looking for any ideas how to solve this.

    Thanks


    Code:
    [...]
    	<ip:tcp-inbound-gateway id="inboundGateway"
    		connection-factory="serverConnectionFactory"
    		request-channel="requestChannel" error-channel="errorChannel"
    		reply-channel="replyChannel" />
    
        <int:channel id="replyChannel" />
    	<int:chain input-channel="requestChannel">
    
    		<int:transformer expression="new String(payload)" />
    		<int:service-activator ref="simpleService" 
    		  method="handleMessage" />
    		  
    	</int:chain>

  • #2
    Just to clarify - I think what I want is something like a temporary response channel for any specific client connected to the server; a sort of messagechannel wrapper that is specific to the socket connection returned from the serverSocket.accept() method.

    Comment


    • #3
      The gateway is purely a request/response environment; you can't send arbitrary messages to the socket.

      See the reference manual section on collaborating channel adapters, which support entirely peer-to-peer messaging.

      For a server connection factory. the inbound adapter "owns" the connection. The outbound adapter addresses a specific socket using the 'ip_connection_id' header.

      For your fist use case (send a response), the message will (usually) already have the header. For your second use case, you would have to capture the header from the inbound message and then insert it in the series of messages sent to the outbound adapter.

      Comment


      • #4
        Gary,
        Thanks for the quick reply.
        Copying the header before sending the message gets rid of the ChannelResolution exception.
        However, it looks like only one message with such a header copy is actually being sent back to the client.
        I'll dig a bit further to see where the message is actually being held up and update the thread.

        Thanks

        Comment


        • #5
          As I mentioned, you can't use a gateway to send arbitrary replies to a single message, just one reply per request.

          However, to support your use case, you can use collaborating channel adapters instead

          Code:
                  <ip:tcp-inbound-channel-adapter id="inboundAdapter"
          		connection-factory="serverConnectionFactory"
          		channel="requestChannel" error-channel="errorChannel" />
          
                  <ip:tcp-outbound-channel-adapter id="outboundAdapter"
          		connection-factory="serverConnectionFactory"
          		channel="replyChannel" />
          
                  <int:channel id="replyChannel" />
          
                  <int:chain input-channel="requestChannel" output-channel="replyChannel">
          
          		<int:transformer expression="new String(payload)" />
          		<int:service-activator ref="simpleService" 
          		  method="handleMessage" />
          		  
                  </int:chain>
          Notice that you have to specify the output-channel on the chain, because there is no replyTo header on messages coming from an adapter (unlike a gateway).

          HTH

          Comment


          • #6
            Gary,

            That's exactly it - thanks a lot! I was (again) looking at the wrong stuff.

            Thx
            C

            Comment

            Working...
            X