keeping the tcp-connection-factory connection open

[mahen]

Hi

I have a 'ip:tcp-connection-factory' setup and shared between a 'tcp-inbound-channel-adapter' and a 'tcp-outbound-channel-adapter'.

following are the configurations:

<ip:tcp-connection-factory id="tcpConnectionFactory"
		type="client" host="${host}" port="${port}" single-use="false"
		so-timeout="${socket_timeout}" serializer="byteArrayStxEtxSerializer"
		deserializer="byteArrayStxEtxSerializer" />


<ip:tcp-inbound-channel-adapter id="inboundClient"
		channel="XX" connection-factory="tcpConnectionFactory" />

<ip:tcp-outbound-channel-adapter id="outboundClient"
		channel="YY" connection-factory="tcpConnectionFactory" />

I need the same connection to be used for all request/response cycles. But currently looks like the connection gets closed after the inbound adapter receives the TCP response, and is using a new connection for the next request sent in the outbound adapter. how can i instruct spring integration to use the same tcp connection , if thats possible.
thanks in advance for any replies.

[Gary Russell]

Are you sure the server is not closing the socket?

We only close the socket after a receipt if single-use="true", but it's false in your config.

How long is the socket_timeout property? In this configuration we don't assume a command/response scenario; the two adapters are independent users of the connection. The timeout will apply on the receiver, regardless of whether something is writing to the socket; it's not like we start a clock when you send a message on the outbound adapter. We will close the socket after a timeout so you need to set the timeout large enough to span the expected time between requests.

Take a look at a debug log, you should see who's closing the socket.

[mahen]

Thanks Garry for this. I know its been a while since my post.
Got a chance to look at this now, as we are planning to go live soon.
I can confirm that the client is closing the socket , as i see following in the client side. Note that the server side is a third party process which is out of my control in terms of access to code.

<code>
2011-11-14 11:03:10,273 [pool-4-thread-1] DEBUG org.springframework.integration.ip.tcp.connection. TcpNetConnection - Read exc
eption <HOST_NAME>:5003:18662056 SocketTimeoutException:null:Read timed out
</code>

and i have set so-timeout to 0 but looks like this is not taking in to effect as i am using 2.0.3.RELEASE
Do i have to use 2.1.0.M3 to get the so-timeout working , or do i have another option.

Thanks.

[Gary Russell]

Yes, you need to move to 2.1.M3 to be able to set it to zero (meaning infinity).

https://github.com/SpringSource/spri...ca3099be1c1bdd

However, with 2.0, you can set it to a very large number as a work-around...

#{ T (java.lang.Integer).MAX_VALUE } represents several weeks.

If you stick with 2.0 (advised for production unless you really need a 2.1 feature), you should upgrade to the latest (2.0.5).

[mahen]

Thanks Garry. I decided to go with 2.0.5 for now, and use the max value for timeout.

I need more clarification on the timeout.
in one of your previous replies in this thread you have mentioned

..We will close the socket after a timeout so you need to set the timeout large enough to span the expected time between requests....

don't think i really get that bit - in my case i am setting single-use to false because i need the same connection to be reused. So in this case isn't the time for timeout calculated starting from the time the connection was created first (i.e the time of first request)? and not time between requests.
FYI, my scenario is explained in the following thread:
http://forum.springsource.org/showth...rver-responses

[Gary Russell]

...don't think i really get that bit...

Yes; there are two reasons to use collaborating adapters with one connection:

1. In a request/response scenario.
2. In a totally asynch; peer-to-peer scenario.

The first allows multiplexing requests/responses (send another request before the response arrives), which is not possible with a gateway - this requires the application to take care of correlation, and be able to deal with responses coming back in a different order (depending on server configuration).

The second allows completely independent messaging between the two systems. Clearly, in this scenario, using the default reply timeout is incorrect and this was a mistake I made.

My comment above assumed the first scenario; it clearly does not apply to the second scenario. In 2.1 we have allowed the timeout to be set to infinity; in 2.2 we will likely change the default to infinity.