Hi guys, First, a little background. JBossMessaging sends messages to a consumer by calling org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(), which, in the case of the bisocket transport. results in a call to org.jboss.remoting.Client.invoke(), which eventually leads to a write on a java.net.Socket. Now, it's true that there is a parameter, "callbackTimeout", that can be used to configure the callback Client and, ultimately, the Sockets used by the Client. But it's important to note that the Socket timeout value, set by Socket.setSoTimeout(), affects blocking reads on the Socket's SocketInputStream. It doesn't affect blocking writes. See, for example, http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoTimeout.... See also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4031100, where someone asked (in 1997!) for a write timeout for Sockets. The request was rejected since they anticipated NIO would eliminate the problem. "thammoud" wrote : | I believe that is a tcp keep alive issue | Yes, I think you'll have to depend on TCP to discover that the connection has failed. Indeed, it's probably a keepalive failure that's causing the exceptions your both seeing. Fortunately, it is possible to configure the keepalive parameters so that the failure is detected more quickly. Unfortunately, as far as I know, you have to set the parameters at the TCP level rather than the Java level. For Linux configuration, see, for example, http://www.linux.org/docs/ldp/howto/TCP-Keepalive-HOWTO/usingkeepalive.html section 3.1, in particular, and for Windows, see, for example, http://msdn.microsoft.com/en-us/library/ms819735.aspx Let us know your results. -Ron View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219345#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...