[
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