[rabbitmq-discuss] Why does the queue drop other messages after the first is consumed?

[Raj Kumar Sanpui]

On Tue, Dec 17, 2013 at 1:29 AM, Raj Kumar Sanpui <
raj.kumar.sanpui at gmail.com> wrote:

> If i have 10 messages in queue, and there are around 5 consumer threads,
> when each of them consume in turn, either using basic.consume or
> amqp.consume.message (the new non-blocking version):
> https://github.com/alanxz/rabbitmq-c/blob/master/librabbitmq/amqp.h#L2151
>
> So, as per you there should not be any thread locks, or the consume to be
> serialized, is not required per se.
> So, basic.consume or amap.consume.message, should be thread safe by itself?
>
> Thanks
>
>
>
> On Tue, Dec 17, 2013 at 1:22 AM, Gavin M. Roy <gavinmroy at gmail.com> wrote:
>
>> Looking through the source of rabbitmq-c I see mutex code around ssl
>> initialization (amqp_openssl.c), but I don’t see how that could cause your
>> issue.
>>
>> I’m wondering why you’d want to mutex either around the RPC request or if
>> you’re calling amqp_consume_message (
>> https://github.com/alanxz/rabbitmq-c/blob/master/librabbitmq/amqp_consumer.c#L136).
>>  What does putting a lock around your “basic_consume()” invocation achieve?
>>
>> Consuming is an asynchronous operation. You register your app as a
>> consumer with RabbitMQ, then as RabbitMQ sees fit, messages are delivered
>> to your application. Without context, I’m interpreting what you’re doing as
>> if you want to use Basic.Get instead.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131217/f8559328/attachment.html>