Well, if the only way for the server to know "the client has processed the message successfully is if it receives an ack", but at the same time server can not wait for an ack forever (in case of client failures), then what is the purpose of an ACK in relation to 'immediate' flag? It seem to be meaningless... right?
Oleg
On Jun 4, 2010, at 1:19 PM, Simon MacMullen wrote:
> On 04/06/10 18:03, Oleg Zhurakousky wrote:
>> Well, 'a' and 'b' are actually different IMHO.
>>>> If I have a consumer with noAck set to 'false', then I am sending the
>> basicAck conditionally inside of the handleDelivery() method. This
>> means that even though handleDelivery() was successfully invoked, the
>> ACK might not have been sent, right?
>> From the perspective of the client, or of an all-knowing observer,
> that's true. From the perspective of the server, suppose it delivers the
> message and then the connection goes away - did the client crash or lose
> power? Did it get as far as invoking handleDelivery() (or whatever the
> client API looks like) or not?
>> The only way it'll know the client has processed the message
> successfully is if it receives an ack.
>> But to return to the immediate flag, my "Hmm" in the last mail may have
> been premature. The spec says:
>> "When a message arrives in a message queue, the message queue tries
> immediately to pass it to a consumer application via AMQP. If this is
> not possible, the message queue stores the message (in memory or on disk
> as requested by the producer) and waits for a consumer to be ready. If
> there are no consumers, the message queue may return the message to the
> producer via AMQP (again, if the producer asked for this)."
>> I think the motivation for this behaviour is that if the server waited
> for an ack, it could have to wait a long time.
>> Cheers, Simon
> _______________________________________________
> rabbitmq-discuss mailing list
>rabbitmq-discuss at lists.rabbitmq.com>http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss