Bug 603204
Summary: | vpn reset caused qpid thread to throw an unhandled exception. | ||
---|---|---|---|
Product: | Red Hat Enterprise MRG | Reporter: | Timothy St. Clair <tstclair> |
Component: | qpid-qmf | Assignee: | messaging-bugs <messaging-bugs> |
Status: | NEW --- | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | beta | CC: | gsim |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Windows | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | --- | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 603085 | ||
Bug Blocks: |
Description
Timothy St. Clair
2010-06-11 20:40:04 UTC
The expected way of communicating loss of transport is the throwing of TransportFailure. I'm assuming you are using the QMF agent API? The question then is whether or not it is supposed to shield you from catching exceptions and convey error status in some other way. Correct we are using qmf. From what I had seen the exception was not thrown into a code path that I could trap on, which means it was unhandled within a thread proc internal to qpid. |