rabiitMQ C apis

[l rus]

What do the following options help acheive:

- amqp_basic_consume
          no_local
          no_ack    =  1      does it turn off ack?  (default is on?)
          exclusive

- amqp_queue_declare
          passive
          durable
          exclusive
          auto_delete

RabbitMQ server expects ack for it to delete delivered msg from the queue.
Does "ack" option to amqp_basic_consume() allow to do that?

[Michael Klishin]

On 20 October 2014 at 22:11:47, l rus (zxto...@gmail.com) wrote:
> > What do the following options help acheive:
>
> - amqp_basic_consume
> no_local

Not implemented by RabbitMQ.

> no_ack = 1 does it turn off ack? (default is on?)

true means "use automatic acknowledgements". So, no_ack = "no manual acknowledgements",
if you will.

> exclusive

Rarely used. Allows you to have only 1 consumer on the queue. It's easier to
simply use an exclusive queue.

> - amqp_queue_declare
> passive
> durable
> exclusive
> auto_delete

These are explained very well by the tutorials on rabbitmq.com.

> RabbitMQ server expects ack for it to delete delivered msg from
> the queue.
> Does "ack" option to amqp_basic_consume() allow to do that?

See above. For manual acks, set no_ack = true. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[l rus]

the client has no_ack=1.

Does this automatically send an ack to the rabbitmq server
after successful delivery of an envelop with amqp_consume_message()
and withhold if any error condition in the RabbitMQ c e.g.
AMQP_RESPONSE_LIBRARY_EXCEPTION / AMQP_STATUS_UNEXPECTED_STATE?

Does RabbitMQ log receipt of ACK by the client?

[Michael Klishin]

 On 20 October 2014 at 22:44:54, l rus (zxto...@gmail.com) wrote:
> Does this automatically send an ack to the rabbitmq server
> after successful delivery of an envelop with amqp_consume_message()
> and withhold if any error condition in the RabbitMQ c e.g.
> AMQP_RESPONSE_LIBRARY_EXCEPTION / AMQP_STATUS_UNEXPECTED_STATE?
>
> Does RabbitMQ log receipt of ACK by the client?

Please, please read the tutorials. Tutorial 2 covers how acknowledgements work.

[l rus]

>> "If consumer dies without sending an ack, RabbitMQ will understand
>> that a message wasn't
<> processed fully and will redeliver it to another consumer."

> They are considered to be acknowledged as soon as the server
> sends them out. Client libraries don't do anything in automatic acknowledgement
> mode.

     I  assumed that with no-ack=1, the client library would internally send basic.ack to the server.

> <from earlier thread>
> When issuing a basic.consume, you explicitly pick which acknowledgement mode you want:
> automatic or manual (client has to send basic.[n]ack).

     If not, what does "automatic ack" in rabbitmq-c client library do?

    
    Since rabbitmq server expects an ack, i would need no-ack=0 and send amqp_basic_ack().
 
    for amqp_basic_ack(),
        - what is "multiple" used for?

    Are there any concerns sending amqp_basic_ack() from the thread receiving
    msg via amqp_consume_message()?

[Michael Klishin]

On 21 October 2014 at 01:44:36, l rus (zxto...@gmail.com) wrote:
> I assumed that with no-ack=1, the client library would internally
> send basic.ack to the server.

This assumption is not correct. 

> >
> > When issuing a basic.consume, you explicitly pick which acknowledgement
> mode you want:
> > automatic or manual (client has to send basic.[n]ack).
>
> If not, what does "automatic ack" in rabbitmq-c client library
> do?

Tell RabbitMQ that this consumer will use automatic acknowledgement
mode and thus the server should not expect any acks from it.

> Since rabbitmq server expects an ack, i would need no-ack=0 and
> send amqp_basic_ack().
>
> for amqp_basic_ack(),
> - what is "multiple" used for?

To ack multiple messages with a single basic.ack method sent on the wire.
In other words, instead of acking a single delivery with delivery_tag = X,
it acks all unacknowledged deliveries with delivery tags up to X (inclusive).
Delivery tags grow monotonically, scoped by channel.

You must ack/nack on the same channel the delivery was received on.

[l rus]

I would appreciate  help to understand failure during message ACK with rabbitmq - c library:

I have the following usage:

        main (thread 1)                primary listener (thread 2)

         channel_open(1)              

         basic_consume(1)                consume_message()

         basic_publish(1)                  

                                                           copy msg from envelop

                                                           basic_ack(chan=1, deltag=1, multi)     // no error if remove this...

                                                           further msg process from local copy

                                                           channel_open(2)

                                                                 amqp_ssl_socket_send()                  ---> fails with self->internal_error = 1 (SSL_ERROR_SSL)

                                                           basic_consume(2)              <<<   (did not succeed with above error, ok with out it..)

                                                        basic_publish(1)

                                                        basic_publish(1)

                                                        basic_publish(1)

                                                              basic_ack(multi)                                    // was added recently for "ACK" 

[Michael Klishin]

On 26 October 2014 at 21:51:05, l rus (zxto...@gmail.com) wrote:
> basic_ack(chan=1, deltag=1, multi) // no error if remove this...

…

> basic_ack(multi) // was added recently for "ACK"

You can't ack a delivery twice, if you do, you get a channel exception.

Please do check RabbitMQ logs, it's absolutely not possible to suggest anything
about "internal_error = 1 (SSL_ERROR_SSL)", except that it's really odd that
you get it after having a connection open. So I doubt it actually has anything
to do with SSL. 

[l rus]

   ACK invocation is based on the incoming message channel / delivery-tag.

   i do not (at least knowingly) ack multiple times.

   amqp_basic_ack(envelope.channel, envelope.delivery_tag, multi=true)    // i have also tried with multi = false..

   

   Does multi=true automatically ack to all pending msgs that were not ACKed

   or uses "delivery_tag" as a "starting" tag?

   As seen in the calling sequence, SSL error occurs only when basic_ack() was

   added to the calling sequence. (all works fine when basic_ack() for there).

   basic_ack() itself seems to have completed successfully.

   But subsequent call to 2nd channel_open() fails..

   

   Unfortunately  I do not have access to rabbitmq server side log. 

[Michael Klishin]

On 26 October 2014 at 22:25:06, l rus (zxto...@gmail.com) wrote:
> amqp_basic_ack(envelope.channel, envelope.delivery_tag,
> multi=true) // i have also tried with multi = false..
>
>
> Does multi=true automatically ack to all pending msgs that were
> not ACKed
> or uses "delivery_tag" as a "starting" tag?

As an upper range bound, "all unacknowledged messages up to delivery_tag" (inclusive).

[l rus]

>>  > If not, what does "automatic ack" in rabbitmq-c client library   

>> do? 

> Tell RabbitMQ that this consumer will use automatic acknowledgement 
> mode and thus the server should not expect any acks from it. 

 

Is server required to accept client's selection not to ack?

In other words, can client avoid sending ACK with this option

even if server was expecting to receive ACK?

> You can't ack a delivery twice, if you do, you get a channel exception.

The client is not sending ack against specific delivery-tag.

Is it fair to expect the AMQP library to ensure sending ACK to un-acked

delivery-tag when "multi" mode is selected?

[l rus]

The following questions are per lack of my understanding and comments/man page

from rabbitmq-c library API:

 1)   AmqpChannel = 1;

    amqp_channel_open_ok_t *chan = amqp_channel_open(_connection, AmqpChannel);

    What does success / failure reflected thru chan?

     Upon success,  I expected  chan->channel_id.bytes to reflect input channel (1) and 

     chan->channel_id.len to be not 0. However,they were not..

 

 2)   amqp_consume_message() occasionally fails with different errors

    (e.g. when the server may be down / unavailable/closed/reject connection etc)

    

   not AMQP_RESPONSE_NORMAL return:

        AMQP_STATUS_HEARTBEAT_TIMEOUT

        AMQP_STATUS_CONNECTION_CLOSED 

   

        AMQP_CONNECTION_CLOSE_METHOD: channel not open?

        AMQP_CHANNEL_CLOSE_METHOD  :

       e.g. additional call to amqp_consume_message()  after error of 

        AMQP_CONNECTION_CLOSE_METHOD or AMQP_STATUS_CONNECTION_CLOSED

         fails with same error.

        However, additioanl call to amqp_consume_message() after getting

         AMQP_STATUS_HEARTBEAT_TIMEOUT crashes in SSL_write.

          How to differentiate and recover from these conditions?