April 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1082) Allow ConnectionValidator to access InvokerLocator parameters

by Ron Sigal (JIRA)

Allow ConnectionValidator to access InvokerLocator parameters ------------------------------------------------------------- Key: JBREM-1082 URL: https://jira.jboss.org/jira/browse/JBREM-1082 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.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.Client.addConnectionListener() creates an org.jboss.remoting.ConnectionValidator, it passes in a reference to itself and the ConnectionValidator accesses the Client's configuration map. However, the Client's configuration map doesn't include (without some action on the part of the calling application) the InvokerLocator parameters. It follows that parameters configured on the server side (e.g., in a *-service.xml or *-beans.xml file in the context of the Application Server) don't get passed to the ConnectionValidator. -- 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

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1084) Allow CallbackPoller to access Client and InvokerLocator parameters

by Ron Sigal (JIRA)

Allow CallbackPoller to access Client and InvokerLocator parameters ------------------------------------------------------------------- Key: JBREM-1084 URL: https://jira.jboss.org/jira/browse/JBREM-1084 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.2.2.SP12, 2.5.0.SP2 (Flounder) When org.jboss.remoting.Client.addListener() creates an org.jboss.remoting.callbackCallbackPoller, it passes in a reference to itself and a metadata map. Currently, the CallbackPoller accesses parameters only in the metadata map, which means that the Client's configuration map and InvokerLocator parameters (which might be configured declaratively on the server side) are not used. -- 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

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-1113) ServerInvokerCallbackHandlers leak when client doesn't shut down

by Ron Sigal (JIRA)

ServerInvokerCallbackHandlers leak when client doesn't shut down ----------------------------------------------------------------- Key: JBREM-1113 URL: https://jira.jboss.org/jira/browse/JBREM-1113 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.5.0.SP3 (Flounder), 2.2.2.SP12 There are two aspects to this problem. 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

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1104) Identity.get() should create a more meaningful RuntimeException message

by Ron Sigal (JIRA)

Identity.get() should create a more meaningful RuntimeException message ----------------------------------------------------------------------- Key: JBREM-1104 URL: https://jira.jboss.org/jira/browse/JBREM-1104 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.ident.Identity.get() fails in the call to InetAddress.getLocalHost(), it throws a RuntimeException like: java.lang.RuntimeException: Exception creating identity: myhost: myhost This problem has been associated, at least in some cases, with problems in the /etc/hosts file. The problem is that the message gives no clue that the underlying problem is a host name problem. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1117) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1117 URL: https://jira.jboss.org/jira/browse/JBREM-1117 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.1 (Flounder) -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1088) MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped)

by Developer JBoss (JIRA)

MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped) ------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1088 URL: https://jira.jboss.org/jira/browse/JBREM-1088 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.SP1 (Pinto) Environment: Windows Reporter: Developer JBoss Priority: Minor During org.jboss.remoting.Client.connect() call, if server "hostname" DNS mapping is not available at client, org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName throws : java.net.UnknownHostException: <hostname> However, calling method: org.jboss.remoting.transport.socket.MicroSocketClientInvoker(InvokerLocator locator, Map configuration) catches this exception and wraps it as new RuntimeException(ex.getMessage()). This looses rootcause exception stack. It is difficult for caller client code to understand the cause of the exception (UnknownHostException). -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-1108) Warn against making ConnectionValidator.validatorPingPeriod shorter than ConnectionValidator.validatorPingTimeout

by Ron Sigal (JIRA)

Warn against making ConnectionValidator.validatorPingPeriod shorter than ConnectionValidator.validatorPingTimeout ----------------------------------------------------------------------------------------------------------------- Key: JBREM-1108 URL: https://jira.jboss.org/jira/browse/JBREM-1108 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) If the parameter org.jboss.remoting.ConnectionValidator.VALIDATOR_PING_PERIOD (actual value "validatorPingPeriod") is set to a value less than the value of ConnectionValidator.VALIDATOR_PING_TIMEOUT (actual value "validatorPingTimeout"), the connection validation process can fail. ConnectionValidator.run() sets the variable isValid to false, sends a PING, and starts an instance of WaitOnConnectionCheckTimerTask. If the PING invocation succeeds, run() sets isValid to true, and WaitOnConnectionCheckTimerTask quietly returns. However, if the response to the PING invocation is delayed, and the ping timeout value is long enough, it is possible for ConnectionValidator.run() to set isValid to false and start a second WaitOnConnectionCheckTimerTask while the first WaitOnConnectionCheckTimerTask is still waiting. Then, if the response to the first PING arrives, the first WaitOnConnectionCheckTimerTask will see that isValid is false and it will declare a connection failure. There's no reason to start a new WaitOnConnectionCheckTimerTask while an existing WaitOnConnectionCheckTimerTask is still running. The point is that validatorPingPeriod should be longer than validatorPingTimeout, so that, if a PING fails, there is time to notify any listeners of the failure and to shut down the ConnectionValidator before sending another PING. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1115) Update jars to match AS 5.1.0.CR1

by Ron Sigal (JIRA)

Update jars to match AS 5.1.0.CR1 --------------------------------- Key: JBREM-1115 URL: https://jira.jboss.org/jira/browse/JBREM-1115 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder) The jars used in the test suite should match the versions that will be used by AS 5.1.0.CR1. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1116) Remove SecurityUtility

by Ron Sigal (JIRA)

Remove SecurityUtility ---------------------- Key: JBREM-1116 URL: https://jira.jboss.org/jira/browse/JBREM-1116 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 Priority: Critical Fix For: 2.5.0.SP3 (Flounder) org.jboss.remoting.util.SecurityUtility is a collection of static methods that wrap security sensitive method calls in a java.security.PrivilegedActionException or a java.security.PrivilegedExceptionAction. It has the advantage of avoiding cluttering the calling code, but it has the significant disadvantage that any code can call these public methods and, using the permissions granted to Remoting, bypass security restrictions. The methods should be migrated out of SecurityUtility and made inaccessible. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1111) CLONE [JBREM-851] - In LeasePinger replace Timer if it has shut down

by Ron Sigal (JIRA)

CLONE [JBREM-851] - In LeasePinger replace Timer if it has shut down -------------------------------------------------------------------- Key: JBREM-1111 URL: https://jira.jboss.org/jira/browse/JBREM-1111 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

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2009