[jira] Resolved: (SANDESHA2-160) Sequence does not support mixed MEPs

"Thomas McKiernan (JIRA)" <[email protected]>
Newsgroups gmane.comp.apache.webservices.fx.devel
Message-ID <307065290.1214299845254.JavaMail.jira@brutus>
     [ https://issues.apache.org/jira/browse/SANDESHA2-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas McKiernan resolved SANDESHA2-160.
----------------------------------------

    Resolution: Fixed

> Sequence does not support mixed MEPs
> ------------------------------------
>
>                 Key: SANDESHA2-160
>                 URL: https://issues.apache.org/jira/browse/SANDESHA2-160
>             Project: Sandesha2
>          Issue Type: Bug
>            Reporter: Thomas McKiernan
>         Attachments: preventDifferentMEPsReusingSequence.patch
>
>
> At the moment there is nothing to stop a user sending an async request response followed by a sync request response.
> In the server there is logic that ties together the request sequence with the response sequence.
> There is also logic in the client that links a request sequence to the destination EPR.
> The net effect is that the second request/response uses the same sequence pair as the first.
> In the case of 1st request response =async, 2nd = sync, we end up with trying to send an "async" type response through a sync backchannel.
> This causes problems at the addressing layer.
>  I believe that we should either 
> 1) use different sequence pairs for different MEP types or
> 2) once a particular client has started sending messages on a sequence to an endpoint then that sequence should not allow any other MEP type to interact with the sequence.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.