[
https://issues.apache.org/jira/browse/QPID-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-5586:
----------------------------------
Description:
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.
was:
If a qpid messaging connection or (I think) a session 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).
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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
