Bug 1181005
| Summary: | receiver.fetch raises KeyError after network glitch | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Pavel Moravec <pmoravec> | ||||||||
| Component: | python-qpid | Assignee: | Ernie <eallen> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Zdenek Kraus <zkraus> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 3.0 | CC: | eallen, iboverma, jross, mcressma, pematous, zkraus | ||||||||
| Target Milestone: | 3.2 | Keywords: | WorkAround | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | python-qpid-0.34-1 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2015-10-08 13:10:04 UTC | Type: | Bug | ||||||||
| 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: | |||||||||||
| Bug Blocks: | 1169416 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Pavel Moravec
2015-01-12 07:37:16 UTC
The infinite recursion in python-qpid-0.30* is solved by removing the patch for https://issues.apache.org/jira/browse/QPID-5852. That patch is being removed for 3.2. Still looking into the KeyError exception. Created attachment 1028385 [details] Check to see if channel is associated with a session before using it https://reviews.apache.org/r/34560/ Created attachment 1028876 [details] set connection.reconnect to false on socket errors From the review: Alan Conway wrote: >There is something more going on here. If the client is re-connecting then it >should be re-connecting on an entirely new connection so sessions should not be >able to clash, the new connection should have no session on it. >It sounds to me like somehow the client is re-using the original connection >after you unblock it at the firewall, which is definitely not right - there >could be all kinds of invalid state in that connections sessions. If the client >decides a connection is faulty it should definitively close it and forget it >before re-connecting and re-establishing sessions. You need to track down >how/why it is managing to use the old connection after it has failed. The engine is reusing the connection because the connection has a reconnect argument. So the new patch will not try and reconnect using the same connection on a socket error. This has the effect of raising the error back to the client. Created attachment 1037366 [details]
Enable force flag in SessionManager::attach
Enables the force flag in SessionManager::attach and sends force=True in python engine if the engine is started with a connection that has existing sessions.
Committed r1684716 http://svn.apache.org/viewvc?view=revision&revision=1684716 This issue was tested on RHEL 6 i386 && x86_64 and RHEL 7 x86_64 with following packages: python-qpid-0.34-2 python-qpid-proton-0.10-2 python-qpid-proton-doc-0.10-2 python-qpid-qmf-0.34-4 qpid-cpp-client-0.34-5 qpid-cpp-client-devel-0.34-5 qpid-cpp-client-devel-docs-0.34-5 qpid-cpp-client-rdma-0.34-5 qpid-cpp-debuginfo-0.34-5 qpid-cpp-server-0.34-5 qpid-cpp-server-devel-0.34-5 qpid-cpp-server-ha-0.34-5 qpid-cpp-server-linearstore-0.34-5 qpid-cpp-server-rdma-0.34-5 qpid-cpp-server-xml-0.34-5 qpid-java-client-0.30-7 qpid-java-common-0.30-7 qpid-java-example-0.30-7 qpid-jms-client-0.5.0-2 qpid-jms-client-docs-0.5.0-2 qpid-jms-client-examples-0.5.0-2 qpid-jms-client-maven-repo-0.5.0-2 qpid-proton-c-0.10-2 qpid-proton-java-0.10.0-1 qpid-proton-java-maven-repo-0.10.0-1 qpid-qmf-0.34-4 qpid-tools-0.34-1 -> VERIFIED Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-1879.html |