[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1763) 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
mingjun jiang (JIRA)
jira-events at lists.jboss.org
Fri Apr 23 02:50:18 EDT 2010
[ https://jira.jboss.org/jira/browse/JBMESSAGING-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12527213#action_12527213 ]
mingjun jiang commented on JBMESSAGING-1763:
--------------------------------------------
Howard,
New finding: my remoting config file I used to compare with yours is for JBM 1.4.2 GA SP1, i.e. the remoting config of JBM 1.4.2 GA SP1 has not those 3 attributes, but I found the remoting config of JBM 1.4.5 GA is the same as yours, except the figures for the following 3 attributes are different from yours
<attribute name="numberOfCallRetries" isParam="true">5</attribute>
<attribute name="pingFrequency" isParam="true">30000</attribute>
<attribute name="pingWindowFactor" isParam="true">71582</attribute>
As what I described, we encountered this problem under JBM 1.4.5 GA and Remoting 2.2.3 SP1, i.e. our remoting config is the same as yours, so I think this problem is not related to config, right?
Another big finding:
1) If we use JBM 1.4.5 and Remoting 2.2.3 SP1, and we set the timeout to a positive value, e.g. 30000, the client side (message listener) could receive message from topic/queue before 30000, whereas the message listenner won't receive any message from topic/queue after 30000, the remoting client won't receive any subsequent messages any more. I desribed this problem previously
2)If we use JBM 1.4.2 and Remoting 2.4.0 SP1, and we set the timeout to a positive value, even though the timeout period is over, the client still can receive message from topic/queue, i.e. the JBM or Remoting won't close the normal connection
I think you can reproduce our original problem according to the procedure I listed as above, and can also reproduce the timeout setting test
> 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/jira/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.6.GA.SP1, 1.4.7.GA
>
> Attachments: 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/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list