[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
by mingjun jiang (JIRA)
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
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------…
[View More]-------
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
[View Less]
13 years, 3 months
[JBoss JIRA] Created: (JBREM-981) CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
by Ron Sigal (JIRA)
CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
-------------------------------------------------------------------------------------------------------------
Key: JBREM-981
URL: http://jira.jboss.com/jira/browse/JBREM-981
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.CR2
Reporter: Ron Sigal
…
[View More] Assigned To: Ron Sigal
Fix For: 2.4.0.GA
>From Galder:
Consider
<servlet>
<servlet-name>Ejb3ServerInvokerServlet</servlet-name>
<description>The ServerInvokerServlet receives requests via HTTP
protocol from within a web container and passes it onto the
ServletServerInvoker for processing.
</description>
<servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
<init-param>
<param-name>locatorUrl</param-name>
<param-value>servlet://${jboss.bind.address}:8080/unified-invoker/Ejb3ServerInvokerServlet</param-value>
<description>The servlet server invoker</description>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Now, let's say you bind to 0.0.0.0. You'll get an exception like this:
13:39:26,856 ERROR [ContainerBase] Servlet /unified-invoker threw load() exception
javax.servlet.ServletException: Can not find servlet server invoker with same locator as specified (servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.getInvokerFromInvokerUrl(ServerInvokerServlet.java:198)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.init(ServerInvokerServlet.java:66)
The problem arises from the fact that Remoting is trying to compare:
servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet
with
servlet://localhost.localdomain:8080/unified-invoker/Ejb3ServerInvokerServlet
So either, ServerInvokerServlet should call ServerInvoker.validateLocator() with locatorUrl, take the return of that and compare that with the list of locators.
Or validateLocator() is modified to have the real original host passed to the InvokerLocator constructor, rather than the transformed or newHost.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 8 months
[JBoss JIRA] Created: (JBREM-1080) Add support for future tasks to RequestContext
by David Lloyd (JIRA)
Add support for future tasks to RequestContext
----------------------------------------------
Key: JBREM-1080
URL: https://jira.jboss.org/jira/browse/JBREM-1080
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: r3 api
Reporter: David Lloyd
Fix For: 3.1.0.Beta1
Right now, the RequestContext keeps track of tasks and threads being used to …
[View More]process a request. If all tasks complete and no reply is sent, it makes sure that the requesting party receives an exception indicating that a reply was never sent. However, if the request listener may wish interact with another framework which uses some asynchronous callback mechanism, from which a reply is to be sent. In this case, all tasks terminate but the reply might still be sent.
To solve this problem, RequestContext needs a method which can wrap a Runnable (or similar) with some type of cancellable Runnable or task object, which can then be called by other frameworks as needed later on. The RequestContext wouldn't consider a request "dead" until all tasks completed and all such wrapped Runnables have also been completed or GC'd.
--
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
[View Less]
14 years, 11 months