Hi Pavel, >From the user perspective ... functions called "move" are usually not expected to loose anything. If you move files with the "mv" or "move" commands and the target disk is full, the files which didn't fit stay in the source location. They are not deleted. I guess one would expect the same from the QMF method with a similar name. Also be aware, that in your case it seems easy for the operator to make sure that he moves only so many messages that fit the target queue. But what if: - Another client is sending messages into the queueu (i.e. the available space changes "on the go") - The limit causing the problem is not the count limit but the size limit ... since the queueMoveMessages takes only number of messages as parameter, it is not easy to determine how many bytes will be actually moved
So in my opinion this must be a bug. Thanks & Regards Jakub On Wed, Sep 4, 2013 at 12:19 PM, Pavel Moravec <[email protected]> wrote: > Hi all, > I identified a use case when moving (via QMF) more messages than the > destination queue can handle causes one message loss. See reproducer when > attempting to move 300 messages to a queue with max count 100: > > > $ qpid-receive -a "ringQueue; {create:always, node:{ x-declare:{ > arguments:{'qpid.max_count':100}}}}" > $ qpid-send -a "fromQueue; {create:always}" -m 1000 > $ qpid-tool > Management Tool for QPID > qpid: list broker > Object Summary: > ID Created Destroyed Index > ======================================= > 117 08:11:52 - amqp-broker > qpid: call 117 queueMoveMessages fromQueue ringQueue 300 {} > qpid: resource-limit-exceeded: Policy exceeded on ringQueue, policy: size: > max=104857600, current=1000; count: max=100, current=100; type=reject > (qpid/broker/QueuePolicy.cpp:92) (7) - {} > qpid: quit > Exiting... > $ qpid-stat -q > Queues > queue dur autoDel excl msg > msgIn msgOut bytes bytesIn bytesOut cons bind > > ========================================================================================================================= > 3d03d063-4f1e-4cc2-822f-00d95d7e42e9:0.0 Y Y 0 0 > 0 0 0 0 1 2 > fromQueue 899 > 1.00k 101 8.99k 10.0k 1.01k 0 1 > ringQueue 100 100 > 0 1.00k 1.00k 0 0 1 > $ > > My question is: is it a bug or intended behaviour? > > On one side, the broker should not lose any message. On the other side, it > is an operator mistake trying to route more messages than the destination > queue can handle.. (and moreover, knowing the method responsible for moving > the messages, it would not be trivial to fix this without performance > impact, I guess). > > Any comments? > > Kind regards, > Pavel Moravec > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
