Hi Andrej, When the exception is thrown, Remoting has just created a new socket and is trying to create an ObjectInputStream, the constructor for which tries to read a stream header. While it's waiting on the stream header, it is informed that the server has closed the socket, as indicated by "java.net.SocketException: Connection reset". The question is, then, what is going on at the server? One possibility, if the server is very busy, is that all of the worker threads are in use and the server tries to interrupt one to reuse it. If that's the case, then increasing the size of the worker thread pool might alleviate the problem. In fact, I see you have already increased it from the default size (300) to 400. Did that reduce the frequency of the exception? It would be very useful to see what's going on at the server by setting the log level for Remoting to TRACE. You can do that by adding | <category name="org.jboss.remoting"> | <priority value="TRACE"/> | </category> | to server/$CONFIG/conf/jboss-log4j.xml. By the way, I see that you've also added | <attribute name="socket.check_connection" isParam="true">true</attribute> | to the EJB3 Connector configuration. If you did that to try to solve this problem, it was a good guess but not relevant to the problem I see in the stacktrace. Setting "socket.check_connection" to "true" will enable an extra round trip communication when the Remoting client tries to reuse a connection from the connection pool. But the problem in the stacktrace occurs when a new connection is being created. If that's the only reason for enabling connection checking, you might want to take it out, since it will introduce extra latency and network traffic. Let me know what happens with the server log. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185561#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...