Bugs item #885053, was opened at 2004-01-26 13:07
Message generated for change (Comment added) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=885053&group_id=22866
Category: JBossMQ
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sebastian Hauer (hauer)
>Assigned to: Scott M Stark (starksm)
Summary: UIL2 thead leak during broken connection attempt
Initial Comment:
We noticed a thread leak in one of our production
environment running JBoss 3.0.8 with the UIL2 JMS layer.
I did a quick test on my machine where I am running
JBoss 3.2.2RC3 and the UIL2 JMS service is listening on
port 443. I tried connecting via a web browser to this
port which triggered as expected a:
java.io.StreamCorruptedException: Caught EOFException
while reading the stream header
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:840)
at
java.io.ObjectInputStream.<init>(ObjectInputStream.java:163)
at
org.jboss.mq.il.uil2.SocketManager$ReadTask.run(SocketManager.java:265)
at java.lang.Thread.run(Thread.java:479)
I looked at the JBoss code and saw that once you open a
connection to the JMS server 2 threads get launched a
socked read thread UIL2.SocketManager.ReadTask# and
socket write thread UIL2.SocketManager.WriteTask# .
When the the mentioned exception happened the read
thread stops nicely yet the write thread keeped on running.
I verified this taking thread dumps on my local jboss
instance:
After the first broken JMS invocation I had:
8 read threads
9 write threads
After the second broken JMS invocation I had:
8 read threads
10 write threads
After the third broken JMS invocation I had:
8 read threads
11 write threads
....
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2004-01-28 09:50
Message:
Logged In: YES
user_id=175228
Neither the inital creation of an object stream to read a
message or write a message were cleaning up both threads.
Both have been fixed by calling replacing the
log.error(...) call with a handleStop(...) call, a two line
change.
Fixed in 3.0 and higher branches.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=885053&group_id=22866
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
