[
https://issues.apache.org/jira/browse/QPID-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened QPID-1488:
------------------------------
Assignee: Alan Conway
I believe this fix is wrong. The messages on a queue are replicated to the
joining member and as part of that the policy will be updated. The only part
missing is those messages in the unacked state as these are transferred
separately, are not pushed onto the delivery queue and thus not reflected in
the computed policy count.
As it stands I believe (a) the policy count may well be incorrect on the new
replica as enqueued messages will be counted twice, (b) more seriously, the
root issue opens the potential for unacked durable messages to be dequeued
without being enqueued first on a new replica.
> QueuePolicy serialization fix for cluster braindump.
> ----------------------------------------------------
>
> Key: QPID-1488
> URL: https://issues.apache.org/jira/browse/QPID-1488
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Environment: tested on F9
> Reporter: michael j. goulish
> Assignee: Alan Conway
> Priority: Blocker
> Attachments: queue_policy_serialization_bug.diff
>
>
> In cluster braindump (when a new member is being added to a cluster) the
> QueuePolicy is not being serialized out as part of the brain dump. As a
> result the newbie cluster can get a mistaken idea of the queue size (in
> bytes).
> After many dequeues, the size can go negative, but since the queue size is an
> unsigned number it wraps around and look like a large positive. Which sets
> off the flow-to-disk code, because it thinks that the queue has gotten too
> large.
> The result: what(): framing-error: Unexpected command start frame.
> (qpid/SessionState.cpp:57)
> This fix just adds a little serialization of the QueuePolicy on to the end of
> the serialization of the Queue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
