[jboss-user] [Remoting] - Re: EJB3/Socket invoker - connection timeouts

[javajedi]

Ok, I wrapped the code in wakeup() inside of a try/catch, with a catch block that looks like this:


  |       } catch (Exception e) {
  |          synchronized (clientpool) {
  |             synchronized (threadpool) {
  |                clientpool.remove(this);
  |                threadpool.add(this);
  |                Thread.interrupted();
  |             }
  |          }
  |          throw e;
  |       }
  | 

and so far no deadlocks, but there were still plenty "mismatch version of JBossSerialization signature" errors spewing.  I tried switching from JBoss Serialization back to Java Serialization.  Instead of the "mismatch version" errors, I got a bunch of these:


  | 2007-06-27 16:37:22,519 156879 ERROR [org.jboss.remoting.transport.socket.SocketServerInvoker] (SocketServerInvoker#0-3873:) Failed to accept socket connection
  | java.lang.reflect.InvocationTargetException
  |         at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
  |         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  |         at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
  |         at org.jboss.remoting.transport.socket.ServerThread.createServerSocket(ServerThread.java:188)
  |         at org.jboss.remoting.transport.socket.ServerThread.wakeup(ServerThread.java:233)
  |         at org.jboss.remoting.transport.socket.SocketServerInvoker.processInvocation(SocketServerInvoker.java:461)
  |         at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:392)
  |         at java.lang.Thread.run(Thread.java:619)
  | Caused by: java.io.EOFException
  |         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279)
  |         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2748)
  |         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
  |         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
  |         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:73)
  |         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:52)
  |         at org.jboss.remoting.transport.socket.ServerSocketWrapper.createInputStream(ServerSocketWrapper.java:56)
  |         at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:76)
  |         at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:54)
  |         at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:50)
  |         ... 8 more
  | 

So I don't think JBoss Serialization is at fault here.  It looks like my socket timeout of 6 seconds was just not long enough to read what it needed before the socket timed out.  I switched the socket timeout back to the default (60 seconds?)  This seems to have halted all of the errors coming from the wakeup() method.

So the key to preventing the deadlock seems to be catching the exception that is coming from wakeup() and resetting the state (i.e. adding the thread back to the threadpool) before continuing.

Does this seem reasonable? 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058488#4058488

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058488