[hosierdm]

I had a similar issue that someone else mentioned in this thread. I had a subscriber that was registered as an ExceptionListener so that I could know when my server was shutdown. The subscriber would attempt to reconnect until it was successful, but I kept getting ping errors from the old connection. ****I tried closing the old connection in the onException() method, but I got errors trying to close my resources, seemingly because the server wasn't running. Does the server need to be running to successfully close the JMS resources? I wouldn't think so, but the errors I received seemed to indicate otherwise.

-David

[adrian.brock]

Which version are you using?

There was a bug where closing a connection stopped on the first error.
This meant it never got to the code that stopped the ping thread.

This has been fixed in recent versions of JBoss.

Regards,
Adrian

[xibin]

I have exception listeners registered for all my connections and verified that connections are being closed. I suspect it is a JBoss bug where the ping thread is not stopped in the case of a connection failure. Begining of the stack trace:

20:45:35,635 WARN [Connection] Connection failure:
org.jboss.mq.SpyJMSException: Exiting on IOE; - nested throwable: (java.net.SocketException: Connection reset)
at org.jboss.mq.Connection.asynchFailure(Connection.java:718)
at org.jboss.mq.il.uil2.UILClientILService.asynchFailure(UILClientILService.java:145)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleStop(SocketManager.java:394)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:331)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
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)

After this exception, the ping timeout exceptions come at some fixed interval. This is a serious problem, can somebody please take a look at it:

21:03:06,345 WARN [Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:718)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1311)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1303)
... 2 more
21:03:06,347 WARN [Connection] Connection failure:
org.jboss.mq.SpyJMSException: Connection Failed; - nested throwable: (java.io.IOException: ping timeout.)
at org.jboss.mq.Connection.asynchFailure(Connection.java:718)
at org.jboss.mq.Connection$PingTask.run(Connection.java:1311)
at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.IOException: ping timeout.
at org.jboss.mq.Connection$PingTask.run(Connection.java:1303)
... 2 more

[brucec]

We are running JBoss 3.2.3 and are having a similar problem that seems to be causing JBoss to periodically max out the CPU on the server thus causing our applications to get very sick.

It seems to me that JBoss should clean up with the 'reset' and not be so critical of a client-side connection that may or may not close properly. Given that a client machine may crash on its own the connection may never get closed properly. Shouldn't the app server expect this from a client? It's easy to say "bad, bad client", but client code is not likely to be as robust as server code even though we all wish it were.

[adrian.brock]

Please start your own threads.

I wish you guys would stop hijacking other people's threads.
If you didn't start the thread and you are not going to help the original poster
don't add noise.

Regards,
Adrian