2009/7/7 Robert Godfrey <rob.j.godf...@gmail.com>:
> 2009/7/7 Aidan Skinner <ai...@apache.org>:
>> Removing that check seems like the right thing to do to me. There's a
>> couple of other oddities like that elsewhere in the stores though. We
>> should really make a decision about how to treat them, but IMO the
>> right thing to do is to persist if *either* the queue or the message
>> is marked as durable.
>>
>
> Definitely not an *either* thing (transient messages on a durable
> queue should certainly not be persisted).  In practice we currently
> put persistent messages in the store regardless of the durability of
> the queue (e.g. even if the queue is a temporary queue).  This is
> wrong really, but because of the messed up way our configuration is,
> people may be depending on it so we would need to make it clear before
> changing.
>
> I would leave as is for the moment - IMHO we should JIRA the whole
> durable message on transient queue thing (if it isn't already) and
> solve that properly as a separate task.
>
> -- Rob

I'm with Rob here for now as the right thing to do for the broker may
not be what people now want us to do. There were steps taken as part
of the flow to disk work that ensured persistent messages were only
persisted on durable queues but we've not had time to revisit that
implementation since its removal.

Martin

>> On 7/7/09, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>>> While looking into QPID-1941 (moved messages remaining in the JMX
>>> viewMessages() results for the old queue, but not being considered
>>> still on the queue) for GSoC I have noticed an inconsistency between
>>> the recovery behaviour of persistent messages which are moved, and
>>> those handled only by the normal message delivery path.
>>>
>>> if (message.isPersistent() && toQueue.isDurable())
>>> {
>>>      store.enqueueMessage(storeContext, toQueue, message.getMessageId());
>>> }
>>>
>>> The above check in the SimpleAMQQueue moveMessagesToAnotherQueue
>>> method means that persistent messages are not moved in the message
>>> store unless the destination queue is durable. As a result, if the
>>> broker is restarted while using a persistence store any persistent
>>> messages which have been moved to a non-durable queue are lost.
>>> However, any persistent messages delivered directly to the same
>>> non-durable queue are currently recovered at startup as the broker
>>> places no such restriction on messages in the normal delivery path, eg
>>> in IncomingMessage:
>>>
>>> if (persistent)
>>> {
>>>     .
>>>     .
>>>     .
>>>     store.enqueueMessage(.....)
>>>
>>> I am not particularly bothered either way by the 'should persistent
>>> messages should be recovered from non durable queues' argument, but I
>>> do think they should be treated equally whether they have been moved
>>> or not. It means changing the previous behaviour of the section, but I
>>> think it should be entirely consistent one way or the other, so...any
>>> objections to me removing the durability check from the move method?
>>>
>>> Robbie
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>>
>>>
>>
>> --
>> Sent from Google Mail for mobile | mobile.google.com
>>
>> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
>> "A witty saying proves nothing" - Voltaire
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>



-- 
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to