Description of problem: Changing efp-file-size on the used store with existing queues breaks the durable queue creation, with unusual error message. Version-Release number of selected component (if applicable): 0-22.35 How reproducible: 100% Steps to Reproduce: # set the efp-file-size and start broker 1. vim /etc/qpid/qpidd.conf efp-file-size=512 2. service qpidd start # create first queue and fill up with some messages 3. ./qc2_spout -c 200 --durable yes --content "$(openssl rand -hex 65535)" "q;{create:always, node:{durable:true}}" # reconfigure the efp-file-size and restart broker 4. service qpidd stop 5. vim /etc/qpid/qpidd.conf efp-file-size=1024 6. service qpidd start # send additional message to existing q 7. ./qc2_spout -c 200 --durable yes --content "$(openssl rand -hex 65535)" "q;{create:always, node:{durable:true}}" # create and send durable messages to a new durable q2 8. /qc2_spout -c 200 --durable yes --content "$(openssl rand -hex 65535)" "q2;{create:always, node:{durable:true}}" # create and send non-durable messages a new durable q3 9. ./qc2_spout -c 200 --durable no --content "$(openssl rand -hex 65535)" "q3;{create:always, node:{durable:true}}" # create and send non-durable messages a new non-durable q4 10. ./qc2_spout -c 200 --durable no --content "$(openssl rand -hex 65535)" "q4;{create:always, node:{durable:false}}" Actual results: [7] # OK # using the previous efp-file-size [8] 2014-02-18 07:24:44 [Client] warning Broker closed connection: 541, illegal-argument: Value for replyText is too large framing-error: Bad close-code: 541: illegal-argument: Value for replyText is too large (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/framing/reply_exceptions.cpp:63) [9] 2014-02-18 07:27:52 [Client] warning Broker closed connection: 541, illegal-argument: Value for replyText is too large framing-error: Bad close-code: 541: illegal-argument: Value for replyText is too large (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/framing/reply_exceptions.cpp:63) [10] # OK Expected results: [8], [9] both should create a new queue accomodating new efp-file-size Additional info: Note that you can use the upstream spout but add the --durable option also the efp-file-size should be configurable by HLAPI parameter for example 'qpid.file_size'
Another way how to easily reproduce is: for i in `seq 9`; do echo "ADDR_${i}_%04d;" ./qc2_connector -c 499 \ --address "ADDR_${i}_%04d;{create:sender,node:{durable:true}}" done
I cannot reproduce this with the latest trunk version of linearstore. I am not using qc2_spout, but rather qpid-send and qpid-receive for testing, but in all other respects, the results seem normal. The linearstore should behave as follows: 1. Any queue created will use the broker default size set by --efp-file-size parameter. 2. Previously created queues will keep their EFP file size settings. 3. It is now possible to use qpid-config to create a queue with efp file size other than the broker default using --durable --efp-pool-file-size. NOTE that if you set the efp partition, it must exist before the broker is started. ie you cannot create a new partition and use it while the broker is running. Summary: If the broker is started using a different --efp-file-size parameter, then all existing queues should continue to use the old value, only newly created queues will use the new value. Setting NEEDINFO, just want to check that I did not miss anything in my attempts to reproduce this error.
I've tested the minimal scenario with qpid-send and following packages: qpid-cpp-server-0.30-5.el6.i686 qpid-cpp-server-linearstore-0.30-5.el6.i686 and bug is still present. Scenario outline: 0. clear previous QLS: rm -fr /var/lib/qpidd/qls/* 1. set-up non default efp-file-size etc/qpid/qpidd.conf efp-file-size=512 2. restart qpidd 3. create durable queue and send some durable messages qpid-send -m 200 --content-size 500 --durable yes -a "q;{create:always, node:{durable:true}}" 4. change the efp-file-size efp-file-size=1024 5. restart broker 6. again create a new durable queue and send durable messages qpid-send -m 200 --content-size 500 --durable yes -a "q1;{create:always, node:{durable:true}}" 2015-01-09 10:32:36 [Client] warning Broker closed connection: 541, illegal-argument: Value for replyText is too large qpid-send: framing-error: Bad close-code: 541: illegal-argument: Value for replyText is too large (/builddir/build/BUILD/qpid-cpp-0.30/src/qpid/framing/reply_exceptions.cpp:63) That is on last packages that are built and available. If you would like, I could test it on the trunk version, just please make a scratch build for me. For your expected items, I agree. That sounds reasonable. But I've really love to have HLAPI parameter to do that also. {node:{properties:{qpid.queue-efp-size: <N>}}} or something like that. also it should be restrictable by ACL, so a parameter in ACL would be nice to have in matter of security.
I believe this issue is fixed by Bug 1160367. It adds the ability to use partitions as described in comment 4. Using the latest trunk code which includes this update, I can no longer reproduce this scenario. I suggest that another check be made for this bug once new packages are built which include the new partition feature.
Changing to POST pending new packages
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