You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Francesco Raviglione <fr...@gmail.com> on 2020/01/24 09:54:53 UTC

Qpid Proton C API multithreading and AMQP 1.0 queue expiration

Dear all,
I am writing you beceause I am trying to use the Qpid Proton library to
create an AMQP client, written in C (thus using as a reference the "C API
reference":
https://qpid.apache.org/releases/qpid-proton-0.30.0/proton/c/api/files.html
).

This client should be able to concurrently receive and send messages
to/from the same broker (ActiveMQ, in my case), using two threads (in
particular, using pthread).

Looking at the documentation, unfortunately, I was not able to find any
example showing how this can be done with proactors.
Reading the "Multithreading" section inside "Advanced Topics", I understand
that, in order to do so in a thread-safe way, I should use two different
connections.
The "send.c" example is creating a proactor ("pn_proactor()"), then binding
it to a new connection using "pn_proactor_connect2()". My first question
is: is it possible to bind two connections to the same proactor? If yes,
how? Should I use somewhere the "pn_connection_wake()" function and use two
"run()" loops as shown in "send.c"?
If not, do I need two different proactors to manage the two connections to
send data in one thread and receive data in the second thread?

Moreover, I read that, in order to set the TTL for a message, I can use
"pn_message_set_ttl()". However, by compiling and running "send.c", I
noticed that, if a certain queue (specified, if I understood it correctly,
as "app.amqp_address"/"argv[3]") does not yet exist on the broker, it is
created.
When working with AMQP 0.9 and RabbitMQ, there was a way to set the
expiration for that queue, other than for single messages, in order to make
it temporary without directly interacting with the broker. As I am not very
expert on AMQP 1.0, do you know if there is any way to do the same in AMQP
1.0, using the C API?

Thank you very much in advance!

Re: Qpid Proton C API multithreading and AMQP 1.0 queue expiration

Posted by Francesco Raviglione <fr...@gmail.com>.
Dear Gordon,
I am very sorry for the big delay in replying you.

Thank you very much for your reply and for the explanation.
Now everything is much clearer.

I will try running the equivalent of the run() loop in the two threads.

Thank you again for your assistance!

Re: Qpid Proton C API multithreading and AMQP 1.0 queue expiration

Posted by Gordon Sim <gs...@redhat.com>.
On 24/01/2020 9:54 am, Francesco Raviglione wrote:
> The "send.c" example is creating a proactor ("pn_proactor()"), then binding
> it to a new connection using "pn_proactor_connect2()". My first question
> is: is it possible to bind two connections to the same proactor? If yes,
> how? Should I use somewhere the "pn_connection_wake()" function and use two
> "run()" loops as shown in "send.c"?

You can execute the equivalent of that run() loop in two concurrent 
threads. The proactor will ensure that events for the same connection 
are not returned to both threads concurrently.

You only need to call pn_connection_wake() if you want to initiate some 
action on that connection that is otherwise idle. (E.g. if there is now 
something to send).

[...]
> Moreover, I read that, in order to set the TTL for a message, I can use
> "pn_message_set_ttl()". However, by compiling and running "send.c", I
> noticed that, if a certain queue (specified, if I understood it correctly,
> as "app.amqp_address"/"argv[3]") does not yet exist on the broker, it is
> created.
> When working with AMQP 0.9 and RabbitMQ, there was a way to set the
> expiration for that queue, other than for single messages, in order to make
> it temporary without directly interacting with the broker. As I am not very
> expert on AMQP 1.0, do you know if there is any way to do the same in AMQP
> 1.0, using the C API?

Unlike the earlier pre-1.0 iterations, AMQP 1.0 does not define a 
configuration schema for queues etc, or prescribe particular properties 
or behaviours for queues outside the ability to interoperably transfer 
messages.

In other words how you configure your broker will depend on which broker 
you are using.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org