Bug 501749 - If an XML exchange is declared durable, the broker crashes on recovery
Summary: If an XML exchange is declared durable, the broker crashes on recovery
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.1.1
Hardware: All
OS: Linux
high
high
Target Milestone: 1.3
: ---
Assignee: Kim van der Riet
QA Contact: Frantisek Reznicek
URL:
Whiteboard:
Depends On:
Blocks: 550151
TreeView+ depends on / blocked
 
Reported: 2009-05-20 15:24 UTC by Ted Ross
Modified: 2015-11-16 00:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Due to incorrect order of recovery procedures, once restarted, a broker with both the store and XML modules loaded and with persistent XML messages enabled was unable to start again. With this update, the order of recovery procedures for the store and XML exchange was altered, and the broker now starts as expected.
Clone Of:
: 550151 (view as bug list)
Environment:
Last Closed: 2010-10-14 16:08:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0773 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging and Grid Version 1.3 2010-10-14 15:56:44 UTC

Description Ted Ross 2009-05-20 15:24:32 UTC
Description of problem:

If an exchange is declared as durable, the broker will fail on subsequent recovery.  This is true of any exchange type supplied by a plug-in.

Version-Release number of selected component (if applicable):

1.1.1

How reproducible:

100%

Steps to Reproduce:
1. Start a broker with the store and xml modules loaded.
2. execute the command "qpid-config add exchange xml myxml"
3. restart the broker
  
Actual results:

The broker will fail with: terminate called after throwing an instance of 'qpid::broker::UnknownExchangeTypeException'

Expected results:

Success, and recovery of the "myxml" exchange.

Additional info:

Comment 1 Ted Ross 2009-05-20 15:25:53 UTC
This is caused by the fact that the broker recovers the store before it loads plug-in modules.  At the time the xml exchange is recovered, the type is as yet unknown.

Comment 2 Ted Ross 2009-05-20 15:28:54 UTC
Sorry,  here are the correct steps to reproduce:

Steps to Reproduce:
1. Start a broker with the store and xml modules loaded.
2. execute the command "qpid-config add exchange xml myxml --durable"
3. restart the broker

Comment 3 Gordon Sim 2009-05-21 12:45:51 UTC
Added handling for this case as r777096 on qpid trunk and r3390 on store.
Moved registration for the xml- and replication- exchanges to earlyInitialise() to allow instances of these types to be recovered (r777073).

Comment 5 Frantisek Reznicek 2010-03-18 10:23:45 UTC
The issue has been fixed, verified on RHEL 4.8 / 5.5 i386 / x86_64 on packages
[root@dhcp-lab-182 ~]# rpm -qa | grep qpid | sort -u
python-qpid-0.7.917557-4.el5
qpid-cpp-client-0.7.916826-2.el5
qpid-cpp-client-devel-0.7.916826-2.el5
qpid-cpp-client-devel-docs-0.7.916826-2.el5
qpid-cpp-client-rdma-0.7.916826-2.el5
qpid-cpp-client-ssl-0.7.916826-2.el5
qpid-cpp-mrg-debuginfo-0.7.916826-2.el5
qpid-cpp-server-0.7.916826-2.el5
qpid-cpp-server-cluster-0.7.916826-2.el5
qpid-cpp-server-devel-0.7.916826-2.el5
qpid-cpp-server-rdma-0.7.916826-2.el5
qpid-cpp-server-ssl-0.7.916826-2.el5
qpid-cpp-server-store-0.7.916826-2.el5
qpid-cpp-server-xml-0.7.916826-2.el5
qpid-dotnet-0.4.738274-2.el5
qpid-java-client-0.7.918215-1.el5
qpid-java-common-0.7.918215-1.el5
qpid-tests-0.7.917717-4.el5
qpid-tools-0.7.917557-4.el5
rh-qpid-cpp-tests-0.7.916826-2.el5
ruby-qpid-0.7.904654-1.el5

-> VERIFIED

Comment 6 Kim van der Riet 2010-10-05 15:16:55 UTC
    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: Restart broker with both store and XML exchange loaded and with persistent XML messages.
Consequence: Broker fails to start.
Fix: The order of recovery for the store and XML exchange was changed.
Consequence: The Broker starts as expected.

Comment 7 Jaromir Hradilek 2010-10-06 14:35:53 UTC
    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,4 +1 @@
-Cause: Restart broker with both store and XML exchange loaded and with persistent XML messages.
+Due to incorrect order of recovery procedures, once restarted, a broker with both the store and XML modules loaded and with persistent XML messages enabled was unable to start again. With this update, the order of recovery procedures for the store and XML exchange was altered, and the broker now starts as expected.-Consequence: Broker fails to start.
-Fix: The order of recovery for the store and XML exchange was changed.
-Consequence: The Broker starts as expected.

Comment 9 errata-xmlrpc 2010-10-14 16:08:15 UTC
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


Note You need to log in before you can comment on or make changes to this bug.