anonymous wrote : | It appears that this thread, which ought to be quickly finding a ServerThread to handle the incoming request, calling ServerThread.start(), and getting back to the call to serverSocket.accept() as quickly as possible, is instead doing some socket I/O. ServerSocketWrapper.java has a method called createInputStream() that creates a new ObjectInputStream. The stack trace shows that the JBossObjectInputStream constructor is reading some bytes from the input stream, but I don't think that this problem is specific to JBoss Serialization, as java.io.ObjectInputStream's constructor also reads bytes from the stream. | | It seems to me that this could be the cause of the problem that we are seeing. Any time that you're doing a blocking socket read like this, you can potentially just sit for a while until the socket times out. When you've got a thread calling serverSocket.accept(), you can't normally afford to do something like this on that thread. | | Does this analysis make sense? Any thoughts/suggestions would be greatly appreciated. | It does indeed make sense. See JIRA issue JBREM-666 (http://jira.jboss.com/jira/browse/JBREM-666 ). This problem was fixed in the Remoting 2.2.0 releases, the most recent of which is 2.2.0.SP4. Which version of the Application Server are you using? The latest GA release, 4.2.0.GA, comes with Remoting 2.2.0.SP4. If you can't upgrade that far, then you might try getting the latest version of EJB3, which, I believe, should work with Remoting 2.2.0. This could cause problems for other Remoting clients which depend on an older version of Remoting. In that case, look into scoped deployment, which allows different applications to use different library versions. See, for example, the wiki page "ClassLoadingConfiguration" (http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration). -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057954#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...