Red Hat Bugzilla – Bug 473088
Cluster does not handle flow-to-disk correctly.
Last modified: 2009-04-21 12:17:53 EDT
Created attachment 324727 [details] Fix null message store so it supports flow-to-disk (in memory) Description of problem: A broker with persistent store may flow message content to disk for large messages or if the queue exceeds a policy limit. It keeps only the message transfer frame in memory. Currently the cluster does not correctly replicate such messages to new members. >> How to fix: Can I use Message::sendContent() in DumpClient to get the >> content from disk? Does it leave the message in store or do I need to >> re-release the content? It would if the content was stored on disk. For NullMessageStore that won't be the case (and we should prevent it being released under those circumstances). In a standard install however the real store will be in place. [[Attached patch for NullMessageStore]] >> Or is there another function (should I write >> one) that will pull the content back in. I'd rather have a FrameSet than >> have the frames sent to a handler since I want to send this thru the >> client stack. We can also do that. We do need to be care of concurrency implications though as a Message may be on more than one queue.
NullMessageStore has been fixed to handle this case. However cluster still needs to call Message::sendContent when replicating messages that have been flowed to disk (or at least disable flowing to disk).
Can't disable, need to add the call to Message::sendContent
testing run one broker ./qpidd --auth no --staging-threshold 1000 --load-module .libs/cluster.so --load-module ~/mrg/trunk/cpp/lib/.libs/msgstore.so --store-dir /tmp/b1/ --cluster-name testCluster declare a queue ./qpid-config add queue publish-consume --durable ./publish --size 2000 --count 10 ./qpidd --auth no --staging-threshold 1000 --load-module .libs/cluster.so --load-module ~/mrg/trunk/cpp/lib/.libs/msgstore.so --store-dir /tmp/b2/ --cluster-name testCluster --port 5673 --data-dir /tmp/b2 need to expand the test sequence to test the data on the second node.
then run ./consume --print-data --log-enable info+ 2009-jan-30 13:31:49 info Connecting to tcp:localhost:5672 2009-jan-30 13:31:49 info Known-brokers update: amqp:tcp:10.16.13.40:5672,tcp:10.16.19.90:5672, amqp:tcp:10.16.13.40:5673,tcp:10.16.19.90:5673 2009-jan-30 13:31:49 info Received: 2009-jan-30 13:31:49 info Data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX can check that the message body is present -- the XXX. if that does not print, then the message content was dropped.
Fix Committed revision 739378.
The issue has been fixed, validated on RHEL 5.3 i386 / x86_64 cluster on packages: qpidd-0.4.744917-1.el5, python-qpid-0.4.743856-1.el5. Validated manually and automatically (qpid_test_mnode_cluster). ->VERIFIED
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/RHEA-2009-0434.html