Cannot delete temporary queue, it is in use.

[mkarrys]

So. I have searched the list and cannot find any resolution to this problem even though there are a few messages about it. I had the problem in the 3.0.x days but my code has been working for awhile but now with 3.2.4 this problem has reared its ugly head again.

So does anybody know how to use TemporaryQueues correctly with message beans so that when you close the client connection the client, and know the server again, do not through exceptions complaining about not being able to delete the temporary queues. I would think that if the client sends a disconnect that the server should dump the temporary queue.


Thanks,
Mike

[mkarrys]

After tracing through the code it looks like the subscriber is not being removed from the queue before the system tries to delete the queue.

[adrian.brock]

Ignored because of lack of information/example.

[mkarrys]

The problem went away when I recompiled the server and client of my application with the 3.2.4 jar's. But I still get a SocketException on the server when I execute queueConnection.close() on the client.

[adrian.brock]

As a DEBUG/TRACE message correct?

[mkarrys]

The exception I get on the server log is the following.

2004-07-06 10:27:59,743 DEBUG [org.jboss.mq.il.uil2.SocketManager] End WriteTask.run
2004-07-06 10:27:59,743 DEBUG [org.jboss.mq.il.uil2.ServerSocketManagerHandler] Exiting on IOE
java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:162)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
at org.jboss.util.stream.NotifyingBufferedInputStream.read(NotifyingBufferedInputStream.java:67)
at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2133)
at java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2313)
at java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2380)
at java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2452)
at java.io.ObjectInputStream$BlockDataInputStream.readByte(ObjectInputStream.java:2601)
at java.io.ObjectInputStream.readByte(ObjectInputStream.java:845)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:279)
at java.lang.Thread.run(Thread.java:534)

When I look at the MQ code it looks like it is trying to reply back to a socket connection that has already been closed.

[mkarrys]

For whatever it is worth I have tracked down with exception to the following code (I think).

org.jboss.mq.il.uil2.SocketManager.java

private void handleStop(String error, Throwable e)
{
.
.
.
replyAll(e);
if (handler != null)
{
handler.asynchFailure(error, e); <== thrown Here
handler.close();
}
.
.
.
}

org.jboss.mq.il.uil2.ServerSocketManagerHandler.java

public void asynchFailure(String error, Throwable e)
{
log.debug(error, e); <= logged here.
}

Someone who knows the read thread, write thread, and the handler interaction stuff better than I might want to look it over.

[adrian.brock]

This is a debug message saying the connection has been closed.
I don't see the relevence.

[mkarrys]

Sorry if I shoo’d a hamster out of the hen house but it would be nice if Jboss didn’t print stack trace's to the log file unless there is actually a problem. I would much rather have the code changed to:

public void asynchFailure(String error, Throwable e)
{
if (trace)
log.trace(error, e);
else
log.debug(error);
}

But thats just me.

[adrian.brock]

Just set the category "org.jboss" to INFO, there is an example in conf/log4j.xml
You'll notice it is much faster as well.