For the "no activity" case, setting the so-timeout should be sufficient (as long as you have a receiving adapter - or other TcpListener - registered with the connection factory. When no data is received for that interval, the framwork will close the connection. This, together with client-mode should satisfy that requirement. If a new message arrives at the adapter after a timeout, but before the client-mode reconnects, the connection will be immediately established.
With 3.0, you can react to the timeout immediately, by calling getConnection() on the factory when the close event is received.
That said, I am not sure I understand why you might want to establish a connection unnecessarily (one that might time out without ever processing a request). Why not just let the connection be established on demand? (unless, of course, your scenario is one where you might want to get unsolicited messages from the server).
For the connection failure case, the outbound adapter performs one retry internally if the write fails. If using a tcp-outbound-gateway instead, no internal retry is atempted, but you can use a RequestHandlerRetryAdvice to add retry capabilities there (it can also be used on the adapter, if you want more than the one internal retry, or you want to apply other policies such as a back-off).
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware