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 <tom.cr...@airtel-atn.com> 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. > > >
