[
https://issues.apache.org/jira/browse/QPID-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15137150#comment-15137150
]
Brian Bouterse commented on QPID-7053:
--------------------------------------
Proposed Solution: A exception notifier handler registration should be
created. This should allow the user to be notified that an exception occurred.
Similar to the
set_message_received_handler registration this could be called
set_exception_handler. This would come with the similar "Use with caution: "
clause indicating that the exception cannot be handled in this callback, but it
should be recorded and fetched at a later time by calling check_error(),
get_error(), or one of the other blocking calls which will raise the Exception
through a normal active codepath.
Via IRC I was told that qpid.messaging has the exception written internally to
an attribute. This pattern is on several types of objects including:
* Connection
* Session
* Sender
* Receiver
Each one of those types would have a set_exception_handler() method added to
it. Each class can provide a __setattr__ method which will call the callback
after the internal error storing attribute is written.
> Exception Notifier Callback
> ---------------------------
>
> Key: QPID-7053
> URL: https://issues.apache.org/jira/browse/QPID-7053
> Project: Qpid
> Issue Type: Improvement
> Components: Python Client
> Affects Versions: 0.32
> Reporter: Brian Bouterse
>
> When making effective use of the message_received callback handler added with
> QPID-5799, an unintended side-effect occurs regarding exception handling.
> The user registers the message_recieved callback using
> set_message_received_handler and then only calls back into qpid.messaging
> when it was told to do so. As a result when a ConnectionError occurs it is
> not raised. This effectively deadlocks the receiver since it can't know to
> call into qpid.messaging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]