[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, 7 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, 7 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, 7 months
[JBoss JIRA] Deleted: (JBREM-1126) CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
by Ron Sigal (JIRA)
[ https://jira.jboss.org/jira/browse/JBREM-1126?page=com.atlassian.jira.plu... ]
Ron Sigal deleted JBREM-1126:
-----------------------------
> CLONE [JBREM-1113] - ServerInvokerCallbackHandlers leak when client doesn't shut down
> --------------------------------------------------------------------------------------
>
> Key: JBREM-1126
> URL: https://jira.jboss.org/jira/browse/JBREM-1126
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Ron Sigal
> Assignee: Ron Sigal
>
> 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, 7 months
[JBoss JIRA] Created: (JBREM-1126) 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-1126
URL: https://jira.jboss.org/jira/browse/JBREM-1126
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.0.SP2 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.1 (Flounder)
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, 7 months
[JBoss JIRA] Created: (JBREM-1124) Invokers need optiion for configuration map parameters to override InvokerLocator parameters
by Ron Sigal (JIRA)
Invokers need optiion for configuration map parameters to override InvokerLocator parameters
--------------------------------------------------------------------------------------------
Key: JBREM-1124
URL: https://jira.jboss.org/jira/browse/JBREM-1124
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.5.1 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2 (Flounder)
org.jboss.remoting.AbstractInvoker, the parent of all client and socket invokers, constructs a map of parameters by taking an InvokerLocator and an optional configuration map. Currently, it adds the elements of the configuration map, if it exists, and then adds the InvokerLocator parameters, if any, It follows that if a parameter is in both, then the value in the InvokerLocator takes precedence.
There should be an option for the values in the configuration map to take precedence.
--
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, 7 months
[JBoss JIRA] Created: (JBREM-1106) CLONE [JBREM-851] - In LeasePinger and TimerUtil replace Timer if it has shut down
by Ron Sigal (JIRA)
CLONE [JBREM-851] - In LeasePinger and TimerUtil replace Timer if it has shut down
----------------------------------------------------------------------------------
Key: JBREM-1106
URL: https://jira.jboss.org/jira/browse/JBREM-1106
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.GA_CP01, 2.2.2.SP2, 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
When all of the TimerTasks running in a java.util.TimerTask have shut down, the TImer will also shut down, at which point it will accept no more TimerTasks. There are places in Remoting where there should be a test which will create a new Timer the attempt to schedule a TimerTask results in an exception.
Two places the problem exists:
1. org.jboss.remoting.LeasePinger, and
2. org.jboss.remoting.util.TimerUtil.
A similar problem is described in JBREM-748 "BisocketClientInvoker should guard agains scheduling on an expired Timer"
Reported by James on Remoting forum.
--
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, 7 months