It would probably be better if you had posted a more complete
examples, its hard for people to know whats really all being done
without seeing any of the context.
>From your note of 'seconds later' and the fact you have work queue
code present I would have to guess perhaps you aren't calling things
in the correct [container/connection/callback] thread, which is the
only thread allowed to call the method (and almost all the others). As
such it would be an illegal use from another thread and probably only
'working' at all by utter luck that nothing was corrupted and will
only eventually happen when some other activity later causes the
proper thread to do work and the IO actually gets processed for your
earlier call as a side effect. If you are causing actions like
open/send/close etc from outside the container/connection/callback
thread then you need to use the work queue construct in most cases to
hand actions off to the container/connection/callback thread (or use
some alternatives to basically do the equivalent offloading yourself
in other ways).
m_connection.default_session().open_receiver() and
m_connection.open_receiver() will be effectively the same in terms of
opening a receiver on the connections shared 'default session'. You
should rarely ever have to explicitly ask for, or close, the default
session as it appears your first code might be doing.
Ah, actually, after typing all that...though multithreading seems the
most obvious cause it also occurs to me that you said 0.34.0, which is
over a year old now, and there were also some timer related fixes in
later releases...so after looking at threading perhaps try the current
0.37.0 release as well to see if anything changes.
(Aside, qpid-proton cpp and qpid-cpp as noted in the subject, are two
very different things)
On Wed, 27 Apr 2022 at 09:23, Millieret, Xavier
<xaviermillie...@eaton.com.invalid> wrote:
>
> Hi all,
>
> I am using on linux the qpid-proton cpp 0.34 library, coupled to activemq
> 5.16 on Debian 11
>
> I don't understand why the code who using session object (or default_session)
> to send or a receive message, when I try to close it (for example, the
> receiver), it's 2 times more important than using a connection and each time
> open a receiver od sender and close it?
>
> Here the code who take 2 times more for a close
>
> m_connection.work_queue().add([=]() {
> m_connection.default_session().open_receiver("queue://myAdress",
> proton::receiver_options().auto_accept(true));
> });
>
> ........
>
> // The close session
> m_receiver.session().close()
>
> // 2 seconds later
> on_session_close(proton::session&)
> {
> cout << "inside on_session_close << endl ;
> }
>
> // This code is 2 times more faster
>
> m_connection.work_queue().add([=]() {
>
>
>
> m_connection.open_receiver(address,
> proton::receiver_options().auto_accept(true));
>
>
> });
>
> ........
> m_receiver.close();
>
> // Arounds milli seconds after
> on_receiver_close(proton::receiver&)
> {
> cout << "inside on_receiver_close << endl ;
> }
>
> In the broker 's literature and theirs clients, the best way is obtain a
> connection, use it to open session, and use the session to send or receive
> message, don't open/close a connection every time who want to send/receive a
> message.
>
> So it's my question about this performance issue.
>
> Xavier Millieret
> Software Engineer
> Engineering Software & Connectivity
> Power Quality and Electronics Division (PQED)
> Immeuble Viseo - Bâtiment A
> 110, rue Blaise Pascal
> 38330 Montbonnot St Martin
> FRANCE
> tel: +33 (0) 4 76 00 66 02
> xaviermillie...@eaton.com<mailto:xaviermillie...@eaton.com>
> www.eaton.com<http://www.eaton.com/>
>
>
>
>
> ________________________________
> Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal,
> Immeuble Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin,
> France ~ Lieu d'enregistrement au registre du commerce: Grenoble ~ Numéro
> d'enregistrement: 509 653 176 ~ Capital social souscrit et liberé:EUR
> 16215441 ~ Numéro de TVA: FR47509653176
>
> ________________________________
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
