[
https://jira.jboss.org/browse/JBMESSAGING-1763?page=com.atlassian.jira.pl...
]
mingjun jiang commented on JBMESSAGING-1763:
--------------------------------------------
Howard,
Please look back at the correspondence between us, i.e. my comments at
"28/Apr/10 10:39 PM" and "30/Apr/10 04:41 AM". I had already
emphasized the test will only test whether the "timeout" setting you suggested
will work, instead of testing "pulling out the cable", regardless the client and
server are on the same machine or not. Actually, our real application client and JBoss
server are on different machine, it already proved the timeout setting doesn't work. I
cannot pass you our real application code to reproduce this problem, so we have to write a
simple test program to reproduce this issue.
Once more, I paste my previous comments here, Hopefully you can understand what I want to
express and what the test program is intended to do:
The problem is JBM 1.4.5 + Remoting 2.2.3 SP1 will kill the normal connection after
timeout, whereas the JBM 1.4.2 + Remoting 2.4.0 SP1 won't do so.
As you suggested and we tested previously, by setting timeout value to a positve value, my
original problem (The failure detection program won't close the failure connection,
which result in increasing currentClientPoolSize ) will be resolved except the normal
connection will be killed after timeout. If the normal connection won't be killed
wrongly, then my original problem will be solved thoroughly, so I only need to conduct the
timeout setting test and give you the trace log, so that you could investigate why JBM
1.4.5 + Remoting 2.2.3 SP1 wrongly killed the normal connection.
We set timeout to 30 seconds, and conduct the timeout test under JBM 1.4.5 & Remoting
2.2.3 SP1. The message sender sent 2 messages, the first message was sent before 30
seconds, then the message receiver can receive it correctly. After 30 seconds, the second
message was sent, but the receiver cannot receive it. Please refer to the server+client
log.
Bisocket connection won't be closed if pulling out the ethernet
cable between client and server. The failure detection code won't close the failure
connection, as a result, the subsequent requests will hang after connection account
exceeds the threshold
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1763
URL:
https://jira.jboss.org/browse/JBMESSAGING-1763
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Remoting
Affects Versions: 1.4.5.GA, 1.4.6.GA
Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging
1.4.5 GA, JBoss Remoting 2.2.3 SP1
Reporter: mingjun jiang
Assignee: Howard Gao
Fix For: 1.4.7.GA
Attachments: jboss-test-log for JBM1.4.5 & Remoting 2.2.3 SP1.zip,
QReceiver.java, QSender.java, remoting-bisocket-service.xml
We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3
SP1. In our application, there are a lot of Message listeners running on the client side,
these message listeners will receive messages from queue/topic deployed in JBoss Messaging
Configuration:
We created our own JMS Connection factory which uses the default remoting connector. As
you know, the default remoting connector is configured to use the bisocket transport. We
didn't change the default value of the remoting connector
During we run our application, we open the JBoss web console to monitor the value of
currentClientPoolSize under "Jboss.remoting" JMX MBean.
How to reproduce this issue:
1. Run 5 message listeners in the client side to receive messages from JBoss Messaging,
then we observe the value of currentClientPoolSize is 10
2. After processing several messages, we manually pull out the ethernet cable. The value
of currentClientPoolSize is still 10.
3. We run another 5 message listeners in client side, then the value of
currentClientPoolSize will become 20
4. After we do the same operations above several times, the value of
currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize
is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and
we will encounter the following exception in server side
2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread]
Worker thread initialization failure
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at
org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859)
at
org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
Conclusion: JBoss Messaging won't close the failure connections if they are caused by
manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will
increase continuously and finally the new client requests will hang
Note: If we killed the process of message listener in client side, then the value of
currentClientPoolSize will decrease to 0 immediately, it seems that the server could
detect the failure connection and perform the corresponding resource releasing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira