April 2011 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1285) Callback Connector for in-jvm connection should create a LocalServerInvoker

by Ron Sigal (JIRA)

Callback Connector for in-jvm connection should create a LocalServerInvoker --------------------------------------------------------------------------- Key: JBREM-1285 URL: https://issues.jboss.org/browse/JBREM-1285 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.4.SP1, 2.2.4 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.4.SP2, 2.2.4.SP1 When the org.jboss.remoting.Client method public void addListener(InvokerCallbackHandler callbackhandler, Map metadata) throws Throwable; or one of its variants is called, it checks if the ClientInvoker is an instance of BidirectionalClientInvoker as part of its determination of whether to set up push or pull callbacks. If the server is in the same jvm, and the parameter "force_remote" is not set to true, then the ClientInvoker will be an instance of LocalClientInvoker, which implements BidirectionalClientInvoker, so that push callbacks will be configured. That means that a callback Connector will be created, whose transport, if not configured in the metadata map, will be derived from the server's InvokerLocator. If, for instance, the transport in the InvokerLocator is "http", the callback Connector will create an instance of CoyoteInvoker. But CoyoteInvoker will create a ServerSocket, which is completely useless since callback invocations will be made by reference. Client.addListener() should check that its ClientInvoker is a LocalClientInvoker, in which case it should use the "local" transport, before deriving the transport from the servers InvokerLocator. Shout out to Justin Bertram for tracking down this problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1284) ServerInvoker does not close StreamHandler in the case of "addstreamcallback"

by Van Halbert (JIRA)

ServerInvoker does not close StreamHandler in the case of "addstreamcallback" ----------------------------------------------------------------------------- Key: JBREM-1284 URL: https://issues.jboss.org/browse/JBREM-1284 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.4.SP1, 2.2.4 Reporter: Ramesh Reddy Assignee: Ron Sigal Fix For: 2.5.4.SP2, 2.2.4.SP1 This started out http://community.jboss.org/thread/163742 and in Teiid project we created a JIRA for this https://issues.jboss.org/browse/TEIID-1511 while debugging for this issue, I found that in ServerInvoker, for "AddStreamCallback" block in the "handleInternalInvocation" method it does not close the stream handler once it is done. This results in open socket connection. I am not sure if this connection closes after some idle time, but in our case user is rapidly going through deploy and undeploy action, results in too many open files. I created a patch and tested with our usecase, the problem no longer exists. Please find attached patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1193) Make principal information available to Remoting clients and servers

by David Lloyd (JIRA)

Make principal information available to Remoting clients and servers -------------------------------------------------------------------- Key: JBREM-1193 URL: https://jira.jboss.org/jira/browse/JBREM-1193 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core Reporter: David Lloyd Fix For: 3.1.0.Beta2 Design an API which may be used to get the principals in force from any SSL or SASL session. On the server side, listeners should be executed with an authenticated Subject if possible; though it might be better to simply make the principal information available and let the application layer perform security duties. -- 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

13 years, 1 month

1
2
0 / 0

[JBoss JIRA] Updated: (JBREM-917) Switch to Remoting 3.x in JBossAS; deprecate 2.x and earlier

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBREM-917?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBREM-917: ------------------------------ Fix Version/s: 3.2.0.Beta1 (was: 3.1.0.GA) > Switch to Remoting 3.x in JBossAS; deprecate 2.x and earlier > ------------------------------------------------------------ > > Key: JBREM-917 > URL: https://issues.jboss.org/browse/JBREM-917 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.2.0.Beta1 > > > Master bug to hold all issues that prevent inclusion of Remoting 3 - based transports for various services in JBossAS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-918) Make "remote:" resilient against connection failure

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBREM-918?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBREM-918: ------------------------------ Fix Version/s: 3.2.0.Beta1 (was: 3.1.0.Beta3) > Make "remote:" resilient against connection failure > --------------------------------------------------- > > Key: JBREM-918 > URL: https://issues.jboss.org/browse/JBREM-918 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: r3 core: remote > Reporter: David Lloyd > Fix For: 3.2.0.Beta1 > > > If a remote connection is dropped, it should be possible to re-establish the connection and resume the session, without the loss of any in-flight requests/contexts/services/etc. As a corollary, it might be worth exploring having more than one connection in a "bundle" to help parallelize the transit load and avoid head-of-line bottleneck problems. Perhaps it is worth looking into multihoming as well. > SSL contexts might be useful here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1254) Should support SASL ANONYMOUS mechanism

by Ron Sigal (JIRA)

Should support SASL ANONYMOUS mechanism --------------------------------------- Key: JBREM-1254 URL: https://jira.jboss.org/browse/JBREM-1254 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Affects Versions: 3.1.0.Beta2 Reporter: Ron Sigal Fix For: 3.1.0.Beta3 Currently, creating a connection to a peer requires authenticating the user through an available SASL mechanism. The SASL provider from Sun supports, for example, CRAM-MD5 and DIGEST-MD5, which require the use of user names and passwords. The ANONYMOUS mechanism would allow the creation of connections without authentication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1192) Detect and utilize confidentiality/integrity protection layer negotiated via SASL

by David Lloyd (JIRA)

Detect and utilize confidentiality/integrity protection layer negotiated via SASL --------------------------------------------------------------------------------- Key: JBREM-1192 URL: https://jira.jboss.org/jira/browse/JBREM-1192 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: remote Reporter: David Lloyd Fix For: 3.1.0.CR1 When SASL negotiation is completed, an option should be consulted to determine whether the SASL wrap mechanism should be used. The option should default to true if SSL was not negotiation, and false if it was; however the user should be able to override this setting. -- 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

13 years, 1 month

1
2
0 / 0

[JBoss JIRA] Updated: (JBREM-833) HTTP Transport Implementation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBREM-833?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBREM-833: ------------------------------ Fix Version/s: 3.2.0.Beta1 (was: 3.1.0.CR1) > HTTP Transport Implementation > ----------------------------- > > Key: JBREM-833 > URL: https://issues.jboss.org/browse/JBREM-833 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Assignee: Ron Sigal > Fix For: 3.2.0.Beta1 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1190) Change logging to conform to standard

by David Lloyd (JIRA)

Change logging to conform to standard ------------------------------------- Key: JBREM-1190 URL: https://jira.jboss.org/jira/browse/JBREM-1190 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA Change logging to adhere to JBossAS standard. -- 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

13 years, 1 month

1
2
0 / 0

[JBoss JIRA] Updated: (JBREM-839) Remoting Endpoint Connector Resource Adapter

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBREM-839?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBREM-839: ------------------------------ Fix Version/s: 3.2.0.Beta1 (was: 3.1.0.CR1) > Remoting Endpoint Connector Resource Adapter > -------------------------------------------- > > Key: JBREM-839 > URL: https://issues.jboss.org/browse/JBREM-839 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.2.0.Beta1 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2011