The connection is single threaded and designed to be used only by
the/a container thread. Doing otherwise, as it sounds like you were,
could likely present itself as you describe, and also likely result in
illegal multithreading, since calling send does not itself cause IO to
occur, but rather the general container processing does and which
could then happen concurrently.

If you want to do e.g a send from another thread you need to hand off
work to occur on the connections container thread, or use your own
constructs to pick up the work using the container thread.

The 'work_queue' is the provided route for things like this in C++:
https://qpid.apache.org/releases/qpid-proton-0.40.0/proton/cpp/api/classproton_1_1work__queue.html

Its used in the examples, e.g:
https://qpid.apache.org/releases/qpid-proton-0.40.0/proton/cpp/api/scheduled_send_8cpp-example.html
https://qpid.apache.org/releases/qpid-proton-0.40.0/proton/cpp/api/multithreaded_client_8cpp-example.html

Alternatively you can e.g wake the container and do your own coordination:
https://qpid.apache.org/releases/qpid-proton-0.40.0/proton/cpp/api/classproton_1_1connection.html#a473371542eaeba6f67660582fe6a6074

This is covered in the "Multithreading"
https://qpid.apache.org/releases/qpid-proton-0.39.0/proton/cpp/api/mt_page.html
 page of the documentation (I linked to the 0.39.0 version for now as
the 0.40.0 page generated with a weird name for some reason).

Robbie

On Wed, 12 Feb 2025 at 13:37, Keller, Tom
<tom.kel...@honeywell.com.invalid> wrote:
>
> I have an application that communicates to the Azure service bus.  I am using 
> qpid proton library version 0.37.0 (running on Debian OS).  I have an issue 
> with the sender I've created where it takes up to 60 seconds for a message to 
> be actually sent to the service bus afte the call to the sender's send 
> function.
>
> I create the sender (using the open_sender function) when I have the first 
> message to send.  The sender reference returned from open_sender() is saved 
> to a variable.  When the on_sendable callback is received the data is sent 
> using this sender.  For this send, the data is received on the service bus in 
> less than 100 msec.  On my next send request, since the sender is already 
> open, I simply call the sender's send function.  For this message (and all 
> other's sent after), it takes up to 60 seconds for the message to be received 
> on the service bus.  Basically this sender is kept open for the duration of 
> the application running.  The sender is closed when the application is closed.
>
> If I change my architecture so that for each message to send I do what is 
> shown below, all messages are sent with a 200 - 300 msec delay.  Most if this 
> delay is due to the open_sender call.
>
>   1.  Open the sender (open_sender())
>   2.  Wait for on_sendable callback
>   3.  Call sender.send to transmit the message
>   4.  Close the sender
>
> This sequence above is the method used in the service_bus.cpp example.
>
> Is there any documentation on the correct way to use the sender?
>
> Tom Keller
> Sr Software Engineer
> Honeywell Intelligrated
> Mobile: 513.304.8396
>
> tom.kel...@honeywell.com<mailto:tom.kel...@honeywell.com>
> www.intelligrated.com<http://www.intelligrated.com/>
>

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

Reply via email to