Bug 514054
| Summary: | [store] Journal can fill under some conditions, and recover from full condition not possible | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Kim van der Riet <kim.vdriet> |
| Component: | qpid-cpp | Assignee: | Kim van der Riet <kim.vdriet> |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Reznicek <freznice> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 1.2 | CC: | esammons, freznice, gsim |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Because a write operation is required when processing a message queue, reaching the maximum storage capacity rendered any recovery impossible. To target this issue, this update introduces a "resize" utility that allows storage to be resized so that the messages can be recovered and delivered as expected. Note that the broker must be stopped in order to run this tool.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-14 16:00:44 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: | |||
|
Description
Kim van der Riet
2009-07-27 19:07:05 UTC
A python tool called resize was written to analyze and resize the journal. The original journal is pushed down into a backup dir, and a new journal created. The remaining records in the old journal are transferred to the new journal. Note that this procedure cannot be carried out on a running broker, but on the store of a stopped broker. The broker is then restarted on the new store. This strategy, while not ideal, does provide a path to data recovery in a journal which has stopped because of becoming full. There are other broker-size strategies which could also be developed, such as tracking the amount of space needed to fully dequeue all existing records, and using this value as a dynamic threshold for enqueue threshold exceptions. These will be left for a later time and version, however. Last update to resize tool: r.3735 The resize tool is included and functional, tested on RHEL 4.8 / 5.5, i386 / x86_64 on packages: 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-qmf-0.7.946106-17.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:
Cause: Under some limited conditions in which the store file size is too small, the store can be filled such that no recovery is possible.
Consequence: While messages are not lost per se, the store cannot deliver the messages because dequeueing them requires a write operation, and this is not possible when the store is full.
Fix: A tool which allows the store to be resized off-line (ie when the broker is not running) has been written.
Result: The store can now be increased in size, which in turn allows messages on the store to be dequeued after recovery.
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 @@
-Cause: Under some limited conditions in which the store file size is too small, the store can be filled such that no recovery is possible.
+Since a write operation is required when processing a message queue, reaching the maximum storage capacity rendered any recovery impossible. To target this issue, this update introduces a utility that allows the storage to be resized, so that the messages can be recovered and delivered as expected. Note that the broker must be stopped in order to run this tool.-
-Consequence: While messages are not lost per se, the store cannot deliver the messages because dequeueing them requires a write operation, and this is not possible when the store is full.
-
-Fix: A tool which allows the store to be resized off-line (ie when the broker is not running) has been written.
-
-Result: The store can now be increased in size, which in turn allows messages on the store to be dequeued after recovery.
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 +1 @@
-Since a write operation is required when processing a message queue, reaching the maximum storage capacity rendered any recovery impossible. To target this issue, this update introduces a utility that allows the storage to be resized, so that the messages can be recovered and delivered as expected. Note that the broker must be stopped in order to run this tool.+Because a write operation is required when processing a message queue, reaching the maximum storage capacity rendered any recovery impossible. To target this issue, this update introduces a "resize" utility that allows storage to be resized so that the messages can be recovered and delivered as expected. Note that the broker must be stopped in order to run this tool.
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 |