[JBoss JIRA] Created: (JBREM-1169) 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
9:37 a.m.
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: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
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
7:23 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-1169) 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
[
https://jira.jboss.org/jira/browse/JBREM-1169?page=com.atlassian.jira.plu...
]
Ron Sigal commented on JBREM-1169:
----------------------------------
Hi MingJun,
The behavior you've described isn't necessarily unexpected. Let me explain.
Each JBossMessaging (JBM) connection from client to server uses a distinct Remoting
org.jboss.remoting.Client, and each Client uses an
org.jboss.remoting.transport.bisocket.BisocketClientInvoker, and each
BisocketClientInvoker manages a pool of connections. Note, however, that multiple Clients
connected to the same server will share a BisocketClientInvoker. A BisocketClientInvoker,
and its connection pool, will be destroyed only when all of the Clients using it are
disconnected, which happens when all of the associated JBM connections are closed. So,
if you
1. create 5 JBM connections,
2. pull the ethernet cable,
3. create 5 mroe JBM connections
it's possible that the new connections are created before the old ones are destroyed
(or after the old ones are recreated, if you have configured automatic failover). In that
case, a single BisocketClientInvoker will be used by the old and new connections, and its
connection pool might continue to grow.
-Ron
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: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
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
4:16 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-1169) 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
[
https://jira.jboss.org/jira/browse/JBREM-1169?page=com.atlassian.jira.plu...
]
mingjun jiang commented on JBREM-1169:
--------------------------------------
Ron, thanks for your reply firstly.
For the example scenario you mentioned:
1. create 5 JBM connections,
2. pull the ethernet cable,
3. create 5 more JBM connections
You said "it's possible that the new connections are created before the old ones
are destroyed ". I want to further emphasize such a fact, that is, after we pull out
the ethernet cable, the old 5 JBM connections will NEVER be closed/destroyed, as a result,
the value of currentClientPoolSize will increase continuously and reach the threshold, and
finally the new client requests will hang.
I was suspecting this issue was related to another JIRA bug:
https://jira.jboss.org/jira/browse/JBREM-947. I also commented on the JBREM-947. Please
refer to it for more details
Finally, we degrade JBM to 1.4.2 GA and use JBoss Remoting jar 2.4.0 SP1 to overcome this
problem. After applying JBM 1.4.2 GA and Remoting 2.4.0 SP1, the behavior is different,
let me use another example to describe the different behavior:
1. Manually set the MaxPoolSize to 20
2. Run 5 clients, the currentClientPoolSize will become 10
3. Pull the ethernet cable, the currentClientPoolSize is still 10
4. Run 5 more clients, the currentClientPoolSize becomes 20. Note, the
currentClientPoolSize is now reaching the MaxPoolSize 20
5. Run another 5 clients, the currentClientPoolSize still keep 20, and the new client
requests could be handled correctly. (In the previous case I reported, if exceeding the
MaxPoolSize, the new client requestes will hang and encounter exception in server side)
6. Exit the last 5 clients properly, the currentClientPoolSize will decrease to 10
7. Exit the first 5 clients properly, the currentClientPoolSize will decrease to 0
It seems that some of connections were reused............
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: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
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
2:14 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-1169) 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
[
https://jira.jboss.org/jira/browse/JBREM-1169?page=com.atlassian.jira.plu...
]
Howard Gao commented on JBREM-1169:
-----------------------------------
Hi Ron, Mingjun,
I think I understand what Minjun said about setting timeout to be a value greater than 0.
If you set timeout to be a positive value, after the cable has been pulled out, the
remoting will eventually timed out and notify JBM to clean up its connections.
Mingjun, if that happens, that means the resource will be correctly cleaned up, you
wouldn't be able see the poolSize keep growing. Am i right?
So the problem seems to be, when timeout is 0, that Remoting won't get a lease time
out and therefore won't notify JBM of the bad connection.
I wonder if that relates to incorrect remoting configuration?
Mingjun, can you please upload the remoting-bisocket-service.xml you are using? Thanks,
Howard
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: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
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
5:25 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-1169) 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
[
https://jira.jboss.org/jira/browse/JBREM-1169?page=com.atlassian.jira.plu...
]
mingjun jiang commented on JBREM-1169:
--------------------------------------
Actually, we are using the default remoting-bisocket-service.xml recommended in JBoss
documentation. Please refer to the post in forum:
http://community.jboss.org/thread/111560?start=0&tstart=0, my colleague Li Lin had
already provided the configuration of remoting-bisocket-service.xml. The timeout value is
0, i.e. default value
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: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
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
1:42 a.m.
New subject: [JBoss JIRA] (JBREM-1169) 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
[
https://issues.jboss.org/browse/JBREM-1169?page=com.atlassian.jira.plugin...
]
Ron Sigal closed JBREM-1169.
----------------------------
Resolution: Rejected
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: JBREM-1169
URL: https://issues.jboss.org/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
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
Labels: Failure, are, be, by, cable, caused, closed, connection, ethernet,
if, manually, out, pulling, they, won't
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, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4538
days inactive
5271
days old
jboss-remoting-issues@lists.jboss.org
5 comments
4 participants
participants (4)
-
Howard Gao (JIRA) -
mingjun jiang (JIRA)
-
Ron Sigal (Closed) (JIRA)
-
Ron Sigal (JIRA)