[JBoss JIRA] Created: (JBREM-1129) Eliminate nondeterminism in Lease updates
by Ron Sigal (JIRA)
Eliminate nondeterminism in Lease updates
-----------------------------------------
Key: JBREM-1129
URL: https://jira.jboss.org/jira/browse/JBREM-1129
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP11, 2.5.0.SP2 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.2.SP12, 2.5.2 (Flounder)
Each time an org.jboss.remoting.LeasePinger sends a ping to a server side org.jboss.remoting.Lease, the ping message includes a sessionId for each org.jboss.remoting.Client connected to the server that holds the Lease. The lease updates its list of connected Clients each time it gets a ping, and it notifies all registered org.jboss.remoting.ConnectionListener's when a Client is removed from the list.
Since the default behavior of the socket (and bisocket) transports is to use a pool of connections, it is possible for ping messages to arrive out of order. There should be a timestamp on each ping message so that out of order messages can be discarded.
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBREM-1128) Introduce connection identity concept
by Ron Sigal (JIRA)
Introduce connection identity concept
-------------------------------------
Key: JBREM-1128
URL: https://jira.jboss.org/jira/browse/JBREM-1128
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.5.1 (Flounder), 2.2.2.SP11
Reporter: Ron Sigal
Assignee: Ron Sigal
Priority: Critical
Fix For: 2.2.2.SP12, 2.5.2 (Flounder)
Currently, a Remoting server can monitor the continued connection to a Remoting client through the use of an org.jboss.remoting.LeasePinger / org.jboss.remoting.Lease pair. The client side LeasePinger sends out pings to the server side Lease, and, as long as the Lease receives timely pings, the connection is considered to be healthy. If a ping fails to arrive, then the Lease informs any registered org.jboss.remoting.ConnectionListener's about the connection failure.
Consider the case in which an org.jboss.remoting.Client crashes, restarts, and recreates a LeasePinger in time for the new LeasePinger to satisfy its corresponding Lease. Then the Lease considers the connection to be intact. Some applications, however, with JBossMessaging being the prime example, might interpret this scenario as the failure and replacement of a connection. Remoting has no way of reporting a failure in this case.
Remoting needs an optional behavior in which a connection is identified with a particular LeasePinger / Lease pair. When a LeasePinger is replaced, then a new connection begins.
On the client side, the health of a connection can be reported by an org.jboss.remoting.ConnectionValidator, which periodically sends a ping to the server and reports a broken connection if it doesn't receive an answer within a configured window. The ConnectionValidator needs to be able to recognize and report on connections identifed by LeasePinger / Lease pairs.
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBREM-1100) Link ServerInvokerServlet instances to Connectors via MBean names rather than locator URLs
by Galder Zamarreno (JIRA)
Link ServerInvokerServlet instances to Connectors via MBean names rather than locator URLs
------------------------------------------------------------------------------------------
Key: JBREM-1100
URL: https://jira.jboss.org/jira/browse/JBREM-1100
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP10
Reporter: Galder Zamarreno
Fix For: 2.2.2.SP12
Following instructions in http://www.jboss.org/community/docs/DOC-9632, you get the following warning
messages when AS/EAP starts up:
11:41:29,289 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer
11:41:29,290 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer
11:41:29,291 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer
11:41:29,292 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer
11:41:29,293 WARN [Connector] jboss.remoting:service=invoker,transport=servlet is already registered with MBeanServer
They come from the other servlet invokers trying to register the default invoker name in the MBeanServer.
A better solution, and a way to avoid these WARN messages, would be for invokerName to work properly and point to the
corresponding connectors rather than using locatorUrl which are prone to error. This was not possible when I started
working on the unified http invokers.
Ron/David, I think we might have discussed using MBean names rather than locator URLs in the past but can't find the email.
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBREM-1122) Checking out JBREM from SVN casuses test case compilation error
by Radim Chlad (JIRA)
Checking out JBREM from SVN casuses test case compilation error
---------------------------------------------------------------
Key: JBREM-1122
URL: https://jira.jboss.org/jira/browse/JBREM-1122
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP12
Environment: Widows XP + eclipse + SVN checkout of branch
JBossRemoting-2.2.2.SP11_JBREM-1112
Reporter: Radim Chlad
Priority: Trivial
Checking out JBREM branch JBossRemoting-2.2.2.SP11_JBREM-1112
from SVN - casuses 2 test case compilation errors
Client.USE_ALL_PARAMS cannot be resolved
ConnectionValidatorDisconnectTimeoutTestCase.java
JBossRemoting-2.2.2.SP11_JBREM-1112/src/tests/org/jboss/test/remoting/connection
line 228 and line 271
probably last version of org.jboss.remoting.Client class is not commited to SVN
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBREM-1119) CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
by Ron Sigal (JIRA)
CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
--------------------------------------------------------------------------------------
Key: JBREM-1119
URL: https://jira.jboss.org/jira/browse/JBREM-1119
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.1 (Flounder), 2.2.2.SP12
1. a. org.jboss.remoting.callback.ServerInvokerCallbackHandler is referenced by org.jboss.remoting.ServerInvoker and by the org.jboss.remoting.ConnectionNotifier, if any, created by ServerInvoker.
b. ServerInvokerCallbackHandler is passed to org.jboss.remoting.ServerInvocationHandler.addListener(), so the application ServerInvocationHandler could also maintain a pointer to ServerInvokerCallbackHandler.
If the application calls org.jboss.remoting.Client.removeListener(), then ServerInvoker will clean up its references to ServerInvokerCallbackHandler, and it will call ServerInvocationHandler.removeListener(), giving the application a chance to remove the reference it holds.
However, if the connection from the client breaks, none of these things happen.
2. There needs to be a ServerInvokerCallbackHandler method that can be called by the application, by, for example, a ConnectionListener, which will cause the references to be removed by ServerInvoker and the applications ServerInvocationHandler.
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBREM-1125) Test for IllegalStateException when calling Timer.schedule()
by Ron Sigal (JIRA)
Test for IllegalStateException when calling Timer.schedule()
------------------------------------------------------------
Key: JBREM-1125
URL: https://jira.jboss.org/jira/browse/JBREM-1125
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.1 (Flounder), 2.2.2.SP11
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.2.SP12, 2.5.2 (Flounder)
When a java.util.Timer has not more TimerTasks in its queue, it can shut itself down, so that subsequent calls to Timer.schedule() will throw a java.lang.IllegalStateException. Therefore, all calls to Timer.schedule() should be inside a try/catch block that will catch IllegalStateExceptions and create a new Timer. Most of these calls in Remoting are already protected, but there are a couple that are not. In particuler,
branch 2.2:
========
* org.jboss.remoting.detection.AbstractDetector.startHeartbeat()
* org.jboss.remoting.util.TimerUtil.schedule()
branch 2.x:
========
* org.jboss.remoting.detection.AbstractDetector.startHeartbeat()
--
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
15 years, 6 months