[jboss-jira] [JBoss JIRA] Closed: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels

Tue Aug 5 22:41:56 EDT 2008

     [ https://jira.jboss.org/jira/browse/JBREM-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBREM-963.
-----------------------------

    Resolution: Done

This is, or at least it should be, implicitly fixed by the new RequestHandler structure.  Which is to say, it's pushed back into the realm of the protocol implementor to get right.

> Work out a mechanism to handle protocol message ordering issues across multiple channels
> ----------------------------------------------------------------------------------------
>
>                 Key: JBREM-963
>                 URL: https://jira.jboss.org/jira/browse/JBREM-963
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: David Lloyd
>             Fix For: 3.0.0.Beta1
>
>
> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira