[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels
David Lloyd (JIRA)
jira-events at lists.jboss.org
Tue Apr 15 23:21:04 EDT 2008
[ http://jira.jboss.com/jira/browse/JBREM-963?page=comments#action_12409048 ]
David Lloyd commented on JBREM-963:
-----------------------------------
The messages have to be ordered like this:
a) All messages must come after the session is opened
b) Requests must come after the client is opened
c) Client open must come after service is opened
d) Request cancel *should* come after the request that is being cancelled
I think (a) can (and may already) be solved within CoreSession. (b) and (c) I think can be solved by making client/service open operations idempotent, and sending an implied client/service open with each request - this would certainly work for HTTP anyway.
(d) isn't as big a deal, since cancel requests can be resent (it's already idempotent).
> Work out a mechanism to handle protocol message ordering issues across multiple channels
> ----------------------------------------------------------------------------------------
>
> Key: JBREM-963
> URL: http://jira.jboss.com/jira/browse/JBREM-963
> Project: JBoss Remoting
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: David Lloyd
> Fix For: 3.0.0-M3
>
>
> When dealing with a protocol using multiple channels (HTTP for example, and possibly a future multi-channel JRPP variant), sending two messages on two different channels can cause ordering issues if the second message sent arrives first.
> For example, sending a context open on channel A, and a request on channel B, may cause the request to be received before the context open message, resulting in the request being rejected with a "no such context" error. Another example is that stream messages must be handled sequentially.
> There are several possible solutions, including but not limited to:
> * for any message B that must come after A, always send A and B on the same channel (problem: HTTP channels are transient, so this won't work for HTTP) (problem: this could load up one channel while leaving other channels empty, even if load-balancing is used)
> * don't send B until after A is acknowledged (problem: acknowledging A might not be possible within the underlying protocol, like if A is sent in an HTTP reply, requiring a separate ACK message, which can lead to performance problems)
> * if a message comes in seemingly unsolicited (like a request on a nonexistant context) or out of sequence (like in a stream), queue the message for some fixed amount of time to see if the context open message arrives (problem: could be a source of DoS on the server; also this is a duplication of what protocols like TCP already do, which means that all the same problems must be in effect re-solved)
> Starting a forum thread to discuss the topic.
--
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
More information about the jboss-remoting-issues
mailing list