On 02/09/2016 10:37 AM, Toralf Lund wrote:
On 08/02/16 18:07, Gordon Sim wrote:
When enqueing a message, the store attaches its own identifier to it
for use when dequeueing the same message. The error message indicates
that this identifier could not be obtained from the message when it
was trying to dequeue.
OK.
I must say I'm struggling to understand why there is dequeuing from the
queue in question at the spot I'm getting the error message, though.
What the application actually does at the time, is to set up a receiver
for a completely different queue.
Is the same session used for subscribing to the queue for which the
error is reported? (or sending to it if it is indeed an LVQ?)
With AMQP 0-10, once a session hits an error, that is reported for all
subsequent attempts to use the session. With asynchronous operations the
error may not be detected immediately when issuing the triggering command.
It is essentially some kind of internal bug. There have been issues
fixed with similar symptoms when using an LVQ[1], or a paged queue[2],
or federation (though this should have been fixed a very long time
ago) [3]. There could be other causes as well.
Right. LVQ is definitely involved.
And it is a durable LVQ?
If possible, I would suggest upgrading as there have been a lot of
changes and fixes since 0.22.
OK. I will certainly consider that.
I'm wondering if there is any way at all to get temporarily out of this
situation, though. Like I said, I didn't use to get this error, and the
application also seems to work when using a different broker, so I'm
assuming it's somehow related to some kind of unexpected state change. I
tried moving away /root/.qpidd and restarting, but it didn't help...
That is strange. Restarting should get rid of all state. How easy is it
to reproduce on that broker? Would generating a protocol trace be
feasible? (The brokers are all the same version? and that hasn't changed
since it worked? Is the store enabled for all of them?)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
