Re: QPIC CPP threading model
On Tue, Jul 13, 2021 at 1:10 PM rahul.sin...@morganstanley.com wrote: > I need it to ensure I can run it on a specific CPU core. Ok, running pstack against the process should show you the thread id for that. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: QPIC CPP threading model
Hello, There is no callback. You could get the thread id from pstack output. Why do you need it? (If you prefer a callback style of API, look at the QPid proton c++ library). I need it to ensure I can run it on a specific CPU core. Best Regards, Rahul -Original Message- From: Gordon Sim Sent: 13 July 2021 12:30 To: users@qpid.apache.org Subject: Re: QPIC CPP threading model On Tue, Jul 13, 2021 at 12:23 PM rahul.sin...@morganstanley.com wrote: > I am using qpid-cpp-1.39.0 and want to create multiple topics and handle > incoming data in the most efficient way. What I have understood is that the > qpid::messaging::Connection, Session and Receiver are all created in the > application thread. When we try to fetch data from the Receiver, this is also > processed in the application thread. But under the hood, it sounds like the > Session might be communicating with the broker in a different thread and > buffering up the incoming data for appropriate receivers to fetch them. I am > inferring this after reading the in line comments for Receiver::fetch() > method which states that "this method will check with the server that there > is no message for the subscription this receiver is serving before returning > false." Correct. There is an IO thread that does all the sending and receiving of data. > Is there a way we can get the thread Id or any Callback from it so that we > can determine the thread id. There is no callback. You could get the thread id from pstack output. Why do you need it? (If you prefer a callback style of API, look at the QPid proton c++ library). > Also is it correct to assume there is only 1 such thread per Session which is > getting data from the other end? There is one IO thread per connection. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley. You may have certain rights regarding the information that Morgan Stanley collects about you. Please see our Privacy Pledge https://www.morganstanley.com/privacy-pledge for more information about your rights. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: QPIC CPP threading model
On Tue, Jul 13, 2021 at 12:23 PM rahul.sin...@morganstanley.com wrote: > I am using qpid-cpp-1.39.0 and want to create multiple topics and handle > incoming data in the most efficient way. What I have understood is that the > qpid::messaging::Connection, Session and Receiver are all created in the > application thread. When we try to fetch data from the Receiver, this is also > processed in the application thread. But under the hood, it sounds like the > Session might be communicating with the broker in a different thread and > buffering up the incoming data for appropriate receivers to fetch them. I am > inferring this after reading the in line comments for Receiver::fetch() > method which states that "this method will check with the server that there > is no message for the subscription this receiver is serving before returning > false." Correct. There is an IO thread that does all the sending and receiving of data. > Is there a way we can get the thread Id or any Callback from it so that we > can determine the thread id. There is no callback. You could get the thread id from pstack output. Why do you need it? (If you prefer a callback style of API, look at the QPid proton c++ library). > Also is it correct to assume there is only 1 such thread per Session which is > getting data from the other end? There is one IO thread per connection. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Commit rights for Tomas Vavricka
Thank you all for giving me the opportunity to be part of the Qpid project. I will do my best to help. Regards, Tomas On Sat, Jul 10, 2021 at 8:03 PM Oleksandr Rudyy wrote: > The vote is now closed with 8 votes in favour and none against. The > vote has passed. > > Kind Regards, > Alex > > On Mon, 5 Jul 2021 at 19:22, Martin Krása wrote: > > > > +1 > > > > On 01/07/2021, Gordon Sim wrote: > > > +1 > > > > > > On Thu, Jul 1, 2021 at 12:23 AM Alex Rudyy wrote: > > >> > > >> Hi folks, > > >> > > >> I'd like to call a vote to offer commit rights to Tomas Vavricka > > >> > > >> Tomas has been contributing to Qpid Broker-J for a couple of years > > >> starting from 2017. In particular, he submitted an initial > > >> implementation of the queue ring policy (QPID-7618) and reject policy > > >> (QPID-7815) for Qpid Broker-J back in 2017. He is an author of > > >> certificate revocation feature in Qpid Broker-J (QPID-8367). Tomas > > >> contributed a number of bug fixes and improvements for Qpid Broker-J > > >> (QPID-83543, QPID-8354,QPID-8456,QPID-8460,QPID-8458,QPID-8459). He > > >> tested and voted on a number of Qpid Broker-J releases. He also has > > >> been raising various issues with Qpid Broker-J and Qpid JMS Client for > > >> AMQP 1.0 in the user mailing list and creating JIRAs for the issues. > > >> > > >> I feel it is time we offer Tomas commit-rights of his own. > > >> > > >> I will close this vote at 00:00 UTC on Friday 9th June, at which timeI > > >> will tally the votes. > > >> > > >> Regards, > > >> Alex Rudyy > > >> > > > > > > > > > - > > > 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 > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
QPIC CPP threading model
Hello, I am using qpid-cpp-1.39.0 and want to create multiple topics and handle incoming data in the most efficient way. What I have understood is that the qpid::messaging::Connection, Session and Receiver are all created in the application thread. When we try to fetch data from the Receiver, this is also processed in the application thread. But under the hood, it sounds like the Session might be communicating with the broker in a different thread and buffering up the incoming data for appropriate receivers to fetch them. I am inferring this after reading the in line comments for Receiver::fetch() method which states that "this method will check with the server that there is no message for the subscription this receiver is serving before returning false." Is there a way we can get the thread Id or any Callback from it so that we can determine the thread id. Also is it correct to assume there is only 1 such thread per Session which is getting data from the other end? Best Regards, Rahul NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent required and/or permitted under applicable law, to monitor electronic communications, including telephone calls with Morgan Stanley personnel. This message is subject to the Morgan Stanley General Disclaimers available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access the links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you acknowledge that you have read, understand and consent, (where applicable), to the foregoing and the Morgan Stanley General Disclaimers. You may have certain rights regarding the information that Morgan Stanley collects about you. Please see our Privacy Pledge https://www.morganstanley.com/privacy-pledge for more information about your rights.
