Bug 518394
| Summary: | Creating durable and cluster-durable queue which has bad --file-count and/or --file-size parameter causes an exception only for first time | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Frantisek Reznicek <freznice> |
| Component: | python-qpid | Assignee: | Kim van der Riet <kim.vdriet> |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Reznicek <freznice> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 1.1.6 | CC: | esammons, gsim |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
When creating queues using the Python tools, certain combinations of file size and number caused the broker to close the connection with an error code, resulting in unpredictable behavior when using the tools to make stores that were larger than default. Because it interfered with parameter-handling for queue sizes larger than the default, this update disables the incomplete auto-expand feature, with the result that queues with non-default sizes can successfully be created without error.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-14 15:57:29 UTC | 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: | 636827 | ||
| Bug Blocks: | |||
|
Description
Frantisek Reznicek
2009-08-20 09:05:37 UTC
One more aspect of the bug. Once JERR_LFMGR_BADAEFNUMLIM exception is thrown (let's assume name 'b3' as above) then there is no chance to declare queue 'b3' until qpidd is restarted. Let me know if I should raise separate BZ for this. This was fixed in r.3525 for a similar bug (Bug 14568), and has been backported to the 1.1.x/1.2 branch. A note on the comment above: JERR_LFMGR_BADAEFNUMLIM is thrown when auto-expand is enabled but the maximum number of expanded files allowed (which can be set as a parameter) is lower than the number of files that already exist or are being set. The fix above disables autoexpand until this feature is complete, currently the I/O handling and core logic is in place, but there is still some peripheral work to complete. Oops, the bug referenced above should be Bug 514568. The behavior definitely changed, but I can currently see that ranges are not checked, desribed as separate linked problem -> bug 636827. The issue describes the JERR_LFMGR_BADAEFNUMLIM message store exception when trying to create queue with VALID durability parameters. Validity range is --file-count=4 ...64 --file-size=1 ... 32768 The recent tests prove that: 1] JERR_LFMGR_BADAEFNUMLIM is not thrown 2] queue[s] are created Although there is another issue touched in bug 636827 that corrent range need to be checked and user should get notified, this is addressed as separate bug 637751. python-qmf-0.7.946106-13.el5 python-qpid-0.7.946106-14.el5 qmf-0.7.946106-17.el5 qmf-devel-0.7.946106-17.el5 qpid-cpp-*-0.7.946106-17.el5 qpid-dotnet-0.4.738274-2.el5 qpid-java-*-0.7.946106-10.el5 qpid-tools-0.7.946106-11.el5 ruby-qpid-0.7.946106-2.el5 -> VERIFIED
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cuase: Some combinations of file size/number when creating queues through the python tools cause the broker to close the connection with JERR_LFMGR_BADAEFNUMLIM.
Consequence: Unpredictable behaviour when using the python tools to make larger than default stores.
Fix: Auto-expand is an incomplete feature in the store. It has parameters which were not printed in the help, but were still being processed in the parameter handling logic. These were interfering with the normal parameter handling for larger-than-default queue sizes. The auto-expand parameters were disabled until the feature is complete.
Result: Larger-than-default queue creation through the python tools works normally.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,7 +1 @@
-Cuase: Some combinations of file size/number when creating queues through the python tools cause the broker to close the connection with JERR_LFMGR_BADAEFNUMLIM.
+When creating queues using the Python tools, certain combinations of file size and number caused the broker to close the connection with an error code, resulting in unpredictable behavior when using the tools to make stores that were larger than default. Because it interfered with parameter-handling for queue sizes larger than the default, this update disables the incomplete auto-expand feature, with the result that queues with non-default sizes can successfully be created without error.-
-Consequence: Unpredictable behaviour when using the python tools to make larger than default stores.
-
-Fix: Auto-expand is an incomplete feature in the store. It has parameters which were not printed in the help, but were still being processed in the parameter handling logic. These were interfering with the normal parameter handling for larger-than-default queue sizes. The auto-expand parameters were disabled until the feature is complete.
-
-Result: Larger-than-default queue creation through the python tools works normally.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html |