FW: RE: external event loop
Hi, Just wondering if there is any feedback on this question. To summarise, in case it's unclear, ... When I detect loss of the underlying tcp connection in my sub-class of connection_driver, I notify the Qpid engine about this by calling either disconnected() or connection().close(). In either case, when I re-establish the tcp connection, I call connect() and dispatch() from within my connection_driver sub-class but nothing happens. Nothing appears in the output buffer. Should that work OR is connection_driver for single use only? Thanks for any help. From: Tom Crowe Sent: Monday, November 6, 2023 4:07 PM To: users@qpid.apache.org Subject: RE: external event loop Hi, So all working fine with Connection_driver and an external event loop. However, when trying to add a 're-connect' feature, the connection_driver based client is unresponsive. Details: 1. When the server fails abruptly, the loss of transport is detected by a socket recv on the client. 2. Two different methods have been separated used to inform the Qpid engine about the situation - disconnected() and connection().close() 3. When the connection_driver detects a new transport connection, connect() and dispatch() are called, but nothing appears in the write buffer. Is connection_driver a 'one-time use only' class? If not, how can I use it to re-establish an amqp connection? Thanks.
RE: external event loop
Hi, So all working fine with Connection_driver and an external event loop. However, when trying to add a 're-connect' feature, the connection_driver based client is unresponsive. Details: 1. When the server fails abruptly, the loss of transport is detected by a socket recv on the client. 2. Two different methods have been separated used to inform the Qpid engine about the situation - disconnected() and connection().close() 3. When the connection_driver detects a new transport connection, connect() and dispatch() are called, but nothing appears in the write buffer. Is connection_driver a 'one-time use only' class? If not, how can I use it to re-establish an amqp connection? Thanks.
Re: external event loop
Yes the tick function is used solely for heartbeat processing. Each peer sets or declines to set its own heartbeat interval independently. If you never call the tick function, you fail to send empty heartbeat frames in time to the peer if required. You also fail to enforce the presence of inbound frames from the peer within the local heartbeat time limit you may have specified. If you have control of both ends of the connection and turn off heartbeats completely, you do not need to call tick or rely on application heartbeat activity to satisfy the wire protocol to keep the connection alive. If you only have control on your side and wish to avoid using the tick call, then your application heartbeat activity must involve sending AMQP frames to the peer no less frequently than specified in the peer’s AMQP connection settings for the remote heartbeat. Such frames would include sending message content or updating credit. Frames sent by the peer to you would not count towards keeping the connection alive. On Mon, Oct 30, 2023 at 12:45 PM Tom Crowe wrote: > Hi, > Any feedback on this point... for connection_driver, must I call tick() > if I'm not interested in Heartbeats ? > > Thanks, > - Tom > > From: Tom Crowe > Sent: Wednesday, October 25, 2023 5:44 PM > To: users@qpid.apache.org > Subject: RE: external event loop > > Thanks Cliff for your helpful answer to this topic way back on June 30th. > > "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." > > I am curious about the tick() function. > Is preserving heartbeats the ONLY purpose of tick() ? > > I don't need to use the heartbeat feature in AMQP because there is a > heartbeat at application level. > So perhaps I don't need to call the tick() function at all ? > > Or does tick() service other needs e.g. message aging in queues OR > timeouts related to settlement OR something else ? > > Thanks. > > From: Tom Crowe > Sent: Friday, June 30, 2023 11:09 AM > To: users@qpid.apache.org<mailto:users@qpid.apache.org> > Subject: 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. > > >
RE: external event loop
Hi, Any feedback on this point... for connection_driver, must I call tick() if I'm not interested in Heartbeats ? Thanks, - Tom From: Tom Crowe Sent: Wednesday, October 25, 2023 5:44 PM To: users@qpid.apache.org Subject: RE: external event loop Thanks Cliff for your helpful answer to this topic way back on June 30th. "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." I am curious about the tick() function. Is preserving heartbeats the ONLY purpose of tick() ? I don't need to use the heartbeat feature in AMQP because there is a heartbeat at application level. So perhaps I don't need to call the tick() function at all ? Or does tick() service other needs e.g. message aging in queues OR timeouts related to settlement OR something else ? Thanks. From: Tom Crowe Sent: Friday, June 30, 2023 11:09 AM To: users@qpid.apache.org<mailto:users@qpid.apache.org> Subject: 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. >
RE: external event loop
Thanks Cliff for your helpful answer to this topic way back on June 30th. "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." I am curious about the tick() function. Is preserving heartbeats the ONLY purpose of tick() ? I don't need to use the heartbeat feature in AMQP because there is a heartbeat at application level. So perhaps I don't need to call the tick() function at all ? Or does tick() service other needs e.g. message aging in queues OR timeouts related to settlement OR something else ? Thanks. From: Tom Crowe Sent: Friday, June 30, 2023 11:09 AM To: users@qpid.apache.org Subject: 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. >
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
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. >
external event loop
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.
