[jira] [Commented] (QPID-5586) qpid::messaging::Session::nextReceiver needs to be able to throw a distinct exception if the session is closed

["Andrew Stitcher (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940875#comment-13940875 ] 

Andrew Stitcher commented on QPID-5586:
---------------------------------------

The simplest solution here would be to introduce a new exception descended from SessionError so that if you were previously catching that you will still get the new exception too.


> qpid::messaging::Session::nextReceiver needs to be able to throw a distinct exception if the session is closed
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-5586
>                 URL: https://issues.apache.org/jira/browse/QPID-5586
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.26, 0.27
>            Reporter: Andrew Stitcher
>            Assignee: Andrew Stitcher
>             Fix For: 0.27
>
>
> If a qpid messaging connection or (I think) a session using the 0-10 protocol is closed in one thread whilst another thread is in Session::nextReceiver(...) then qpid::ClosedException will be thrown.
> This is definitely wrong! (There is no way to catch this exception using only the messaging library).
> Using the 1.0 protocol a viable exception is throw (qpid::messaging::SessionError) but there is no way to tell that the session has been closed rather than a more general error.
> It seems that there needs to be a new qpid::messaging exception to cover the case that you were waiting for a receiver and the whole session has gone away. Certainly you need to know that you can't refer to the session any more.
> It cannot be sufficient to assert that you must keep sessions around until all the nextReceiver() calls using them are finished with the current API as there is no way to preempt those calls externally. So a service loop waiting to for a receiver to process will be stuck waiting until the session closes. Even if you poll by using timeouts there is no way on return to tell that the session you were just listening on is dead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org