Re: Differences in on_*
They are different ways of doing a similar thing, at different times. One differentiator might be whether you intend to both send and receive, or just one. The helloworld creates a connection, then later after knowing it has been opened, creates *both* a sender and receiver on that connection (on the hidden 'default session' that is also then created first...it could instead manually create a session then create a sender/receiver on it). The simple send example is only going to send, so it immediately 'lines up' creation of the connection, the hidden 'default session', and then a sender right at the outset without waiting for the connection to actually open (which it might not). On Thu, 29 Jun 2023 at 11:15, Tiaan Wessels wrote: > > Thanks for the explanation. Some of the Qpid-Proton C++ examples calls > connect from on_container_start and then open_sender/receiver from > on_connection_open (helloworld) and others calls open_sender directly from > on_container_start (simple_send). When would you use either approach ? I > presume this is due the default session you refer to ? > > On Fri, 9 Jun 2023 at 10:33, Robbie Gemmell > wrote: > > > The 'transport' is somewhat conceptual and handles > > generating/sending/receiving the AMQP frames/protocol bytes over the > > TCP transport connection, based on the activity of the related AMQP > > 'connection' object and its children, with these all relating closely > > to actual AMQP protocol entities. The connection can have sessions, on > > which actual senders and receivers are created and send/receive > > messages. The callbacks relate to each of these entities being opened > > against the peer (e.g a broker). Some of the APIs simplify this by > > creating a 'default session' to allow dealing more directly with > > creating senders and receivers on. > > > > On Thu, 8 Jun 2023 at 11:50, Tiaan Wessels wrote: > > > > > > Hi, > > > What is the differences between > > > on_transport/connection/session/sender/receiver_open? The docs are scant > > on > > > explanations. > > > Thanks > > > > - > > 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
[RESULT][VOTE] Release Apache Qpid JMS 1.10.0
There were 4 binding +1 votes, 1 community +1 vote, and no other votes received. The vote has passed. I will add the files to the dist release repo and release the maven staging repo shortly, updating the website and announcing after the release has had time to sync to the CDN and maven central. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[RESULT][VOTE] Release Apache Qpid JMS 2.4.0
There were 4 binding +1 votes, and no other votes received. The vote has passed. I will add the files to the dist release repo and release the maven staging repo shortly, updating the website and announcing after the release has had time to sync to the CDN and maven central. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: external event loop
Discovered that search function on mail lists is returning hits, albeit hidden from view. Found enough info to work from. Thanks, - Tom On 2023/06/28 14:12:14 Tom Crowe wrote: > Hi, > I have a working prototype with qpid proton c++ v0.37 consuming an amqps > 1.0 data feed. > > Next, I would like to incorporate the prototype into existing software. That > software has other networking interfaces and has a select() based event loop. > > How can I incorporate my qpid proton prototype into this event loop? > > I am encouraged when I see the 'connection_driver' class which is 'designed > to work with a classic reactor'. > I am discouraged by the fact that I see 'support for third party event loop' > as a nice-to-have feature in the README. > > Is it possible to incorporate my qpid proton c++ client into the existing > event loop? > If yes, how? > Are there any examples of this? > > Thanks for your help. > - Tom. >
[ANNOUNCE] Apache Qpid JMS 1.10.0 released
The Apache Qpid (https://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 1.10.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, https://www.amqp.org), based around the Apache Qpid Proton protocol engine and implementing the AMQP JMS Mapping as it evolves at OASIS. The release is available now from our website: https://qpid.apache.org/download.html Binaries are also available via Maven Central: https://qpid.apache.org/maven.html Release notes can be found at: https://qpid.apache.org/releases/qpid-jms-1.10.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid JMS 2.4.0 released
The Apache Qpid (https://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 2.4.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, https://www.amqp.org), based around the Apache Qpid Proton protocol engine and implementing the AMQP JMS Mapping as it evolves at OASIS. Note the 2.x client releases use Jakarta Messaging 3.1 and its "jakarta.jms" package. For existing "javax.jms" use cases continue to use the 1.x client releases. The release is available now from our website: https://qpid.apache.org/download.html Binaries are also available via Maven Central: https://qpid.apache.org/maven.html Release notes can be found at: https://qpid.apache.org/releases/qpid-jms-2.4.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[RESULT][VOTE] Release Apache Qpid protonj2 1.0.0-M16
There were 4 binding +1 votes, and no other votes received. The vote has passed. I will add the files to the dist release repo and release the maven staging repo shortly. The website will be updated after the release has had time to sync to the mirrors and maven central. -- Tim Bish - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid protonj2 1.0.0-M16 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache ProtonJ2 1.0.0-M16. This is the latest release of our AMQP Java client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org), based around the Apache Qpid ProtonJ2 protocol engine also contained in this release. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-protonj2-1.0.0-M16/release-notes.html Thanks to all involved, - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: external event loop
Hi Tom, As a further note to whatever you have found so far... The recommended route would be for you to retain your existing code based on proton::container, and allow it to run with its own dedicated thread (or threads) using its own epoll loop and let Proton manage the sockets for the AMQP connections. You would pass work into Proton using proton::work_queue. Any of your code that runs on a Proton thread (i.e. messaging_handler callback) would pass data and control information out to the rest of your application (without blocking). See cpp/docs/mt.md and cpp/examples/multithreaded_client_flow_control.cpp If you must manage the AMQP connection's IO yourself, then the connection_driver class is a solid choice. The gotchas are to make sure to call the tick() function regularly to preserve heartbeats and to note that both input to and output from the driver can generate new events to be dispatched. A further caveat against connection_driver is that the Proton IO model may change in the near future from byte streams to buffer lists as we pursue performance improvements. This will affect the connection driver interfaces quite intrusively. If you work from a container, as recommended, your program logic is expected to remain stable going forward. Cliff On Fri, Jun 30, 2023 at 3:08 AM Tom Crowe wrote: > > Discovered that search function on mail lists is returning hits, albeit > hidden from view. > Found enough info to work from. > Thanks, > - Tom > > On 2023/06/28 14:12:14 Tom Crowe wrote: > > Hi, > > I have a working prototype with qpid proton c++ v0.37 consuming an amqps > > 1.0 data feed. > > > > Next, I would like to incorporate the prototype into existing software. > > That software has other networking interfaces and has a select() based > > event loop. > > > > > How can I incorporate my qpid proton prototype into this event loop? > > > > I am encouraged when I see the 'connection_driver' class which is 'designed > > to work with a classic reactor'. > > I am discouraged by the fact that I see 'support for third party event > > loop' as a nice-to-have feature in the README. > > > > Is it possible to incorporate my qpid proton c++ client into the existing > > event loop? > > If yes, how? > > Are there any examples of this? > > > > Thanks for your help. > > - Tom. > > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
