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
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
