I know next to nothing about the C++ codes so I cant help any more in that regard than I have. I am also confused by your mention of connections this time when you were talking about receivers the prior time.
No, you cant change the address of a receiver once opened, they are created for a specific address. You would need to change your overall operations approach to use the more efficient / typical approach of reusing an address for consuming from (e.g utilising correlation-id's to correlate responses with requests, if this is for request-response) so that you could leave open / reuse the same receiver to consume multiple messages, rather than inefficiently creating lots of new consumers and using a different address for every operation. Or perhaps be receiving from a server that can wildcard its addresses to receive from more than one destination. On the sending side the equivalent more-efficient use case is to use a single 'anonymous sender' over time, created without an address, and have each message carry the specific address it is being sent to...plus perhaps a correlation-id if looking to correlate responses to specific messages. On Mon, 8 Aug 2022 at 12:19, Clappier, Eric <ericclapp...@eaton.com.invalid> wrote: > > Hello Robbie, > Thanks a lot for your response. > I see no api to clear link objects with C++ library. > I don't know how the link objects are managed internally by the library but I > made some test with a lot of connection > (more than 100000) and wait a little to see that happened. The connections > are still present, all closed and not active. > I don't know how to remove them correctly. Is there a sort of garbage > collector to clean the structure after a delay > manage by the library... > Of course, I try to reuse receiver (or sender) but to change the address for > the receiver, there is only the > open_receiver (const std::string &addr) api for that. > So need to re-open a new receiver each time. > BR > > > > ----------------------------- > 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é:€ 16215441 > ~ Numéro de TVA: FR47509653176 > > ----------------------------- > > -----Original Message----- > From: Robbie Gemmell <robbie.gemm...@gmail.com> > Sent: lundi 8 août 2022 11:33 > To: users@qpid.apache.org > Subject: [EXTERNAL] Re: [qpid-proton-c++] Receiver list not clear > > I believe there is a 'free' method in the C library, to clear out link > objects when they are done with (i.e locally and remotely closed). I dont > know if the C++ stuff exposes that. If it doesnt it should probably be > managing the 'freeing' itself. > > Of course, there is a simpler way to avoid a buildup of receivers: > reuse a single receiver, stop creating and closing one for each request. > Naturally that depends on what specifically it is you are doing, but creating > receivers (or senders) per message is inefficient and so not generally > advisable. > > On Tue, 2 Aug 2022 at 12:31, Clappier, Eric <ericclapp...@eaton.com.invalid> > wrote: > > > > Dear all, > > > > I am writing an amqp client with Qpid proton C++ 0.34 on Debian 10. > > I create one client connection which I had some senders and some receivers > > on it. > > For example with a request, I create a sender to send the message and a > > receiver for the reply message. > > When I create a receiver in my default session for a particular address > > (queue), the receiver appear in the receiver list of the session. > > After receive the message, when I close the receiver with > > "receiver.close()", the receiver is closed but it still present in the > > default session list. > > Its state is closed and none active. > > When I receive another message, the list increase indefinitely and was > > never clear. > > Is there a way to prevent the list from growing indefinitely without > > closing the connection ? > > > > Any help will be appreciate. > > > > Regards > > > > Eric Clappier > > > > > > > > ________________________________ > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
