March 2010 - jboss-remoting-issues

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

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-918?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-918: ------------------------------ Fix Version/s: 3.1.0.Beta2 (was: 3.1.0.Beta1) > Make "remote:" resilient against connection failure > --------------------------------------------------- > > Key: JBREM-918 > URL: https://jira.jboss.org/jira/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.1.0.Beta2 > > > 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. - 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

14 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-827) Define a management interface for JBoss Remoting

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-827?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-827: ------------------------------ Fix Version/s: 3.1.0.Beta2 (was: 3.1.0.Beta1) > Define a management interface for JBoss Remoting > ------------------------------------------------ > > Key: JBREM-827 > URL: https://jira.jboss.org/jira/browse/JBREM-827 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.1.0.Beta2 > > -- 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

14 years, 9 months

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-833?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-833: ------------------------------ Fix Version/s: 3.1.0.CR1 (was: 3.1.0.Beta1) > HTTP Transport Implementation > ----------------------------- > > Key: JBREM-833 > URL: https://jira.jboss.org/jira/browse/JBREM-833 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Assignee: Ron Sigal > Fix For: 3.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

14 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-929) Secure remote classloading

by David Lloyd (JIRA)

Secure remote classloading -------------------------- Key: JBREM-929 URL: http://jira.jboss.com/jira/browse/JBREM-929 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it. Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came. -- 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

14 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1016) Increase Basic Protocol Version

by David Lloyd (JIRA)

Increase Basic Protocol Version ------------------------------- Key: JBREM-1016 URL: https://jira.jboss.org/jira/browse/JBREM-1016 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA Increase the protocol version by one. Clone this issue for every minor release. -- 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

14 years, 9 months

1
1
0 / 0

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

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-839?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-839: ------------------------------ Fix Version/s: 3.1.0.CR1 (was: 3.1.0.Beta1) > Remoting Endpoint Connector Resource Adapter > -------------------------------------------- > > Key: JBREM-839 > URL: https://jira.jboss.org/jira/browse/JBREM-839 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.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

14 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1196) KRB/GSSAPI Support

by David Lloyd (JIRA)

KRB/GSSAPI Support ------------------ Key: JBREM-1196 URL: https://jira.jboss.org/jira/browse/JBREM-1196 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: remote Reporter: David Lloyd Fix For: 3.2.0.Beta1 Add support for KRB/GSSAPI support with SASL and/or JSSE. -- 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

14 years, 9 months

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-918?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-918: ----------------------------------- One option might be to drop in-flight requests with IndeterminateOutcomeException, but keep the clients "active" but dormant until the connection can come up, and if the connection does not return in some amount of time, the clients can all be asynchronously closed. > Make "remote:" resilient against connection failure > --------------------------------------------------- > > Key: JBREM-918 > URL: https://jira.jboss.org/jira/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.1.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. - 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

14 years, 9 months

1
0
0 / 0

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

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-918?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-918: ----------------------------------- The problem is that then when a connection is broken, all state must be maintained for some predetermined amount of time. This is a substantial amount of state - it can encompass any number of clients and streams and even in-flight requests and replies which may have been partially sent. Perhaps this ties into graceful shutdown - if a connection is gracefully shutdown, then all clients and connections are closed, otherwise the information is all kept? > Make "remote:" resilient against connection failure > --------------------------------------------------- > > Key: JBREM-918 > URL: https://jira.jboss.org/jira/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.1.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. - 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

14 years, 9 months

1
0
0 / 0

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

by Trustin Lee (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-918?page=com.atlassian.jira.plug... ] Trustin Lee commented on JBREM-918: ----------------------------------- SSLContexts should be allowed to be reused regardless if the connection was dropped, closed cleanly, or there was no prior connection. That is, a user should be able to specify an option when making a connection attempt, just like he/she can do for socket options. On a dropped connection, any in-progress requests should be notified (via IoFuture) so that the client is aware of possibility of duplicate requests on redelivery or dropped requests on non-redelivery. i.e. it should never be retried silently. What other contextual information would we need to retain on disconnection for quick resilence? If it doesn't take much time and it's not CPU intensive, we might not need this feature, except for SSLContext reuse? > Make "remote:" resilient against connection failure > --------------------------------------------------- > > Key: JBREM-918 > URL: https://jira.jboss.org/jira/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.1.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. - 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

14 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2010