On Fri, 2016-10-07 at 03:13 -0700, Tobias Duckworth wrote: > Thank you very much for the detailed explanation. > > I managed to get this going quite simply: > > 1) Added a pure virtual method on connection_engine, > connection_engine::tick(). > > 2) Added a public function pn_timestamp_t > connection_engine::tick_check(pn_timestamp_t now) > > 3) Added some logic to connection_engine::dispatch that checks > pn_event_type > for whether it's a PN_TRANSPORT event, and if so sets a boolean to > call the > connection_engine::tick() method. > > 4) Implemented the connection_engine::tick() method in my derived > class, > which gets the current time in milliseconds, then calls > connection_engine::tick_check(now). If the returned value is greater > than > zero a timer is setup for the number of milliseconds returned, which > on > expiry calls the tick() method in the derived class. > > With these four steps the underlying transport sends heartbeats at > half of > the remote_idle_timeout specified in the response to the connect > packet. > > Thanks again, > Toby >
Advertising
This will work *provided* you call dispatch() often enough. If your application goes quiet for a period of time then you can miss heartbeats unless you have some external timer set to poke the engine periodically. If you do have that (e.g. a poll timeout or something) then you should be set. That's why I'm still not sure I want to put this logic directly into the engine - setting up the external timer is platform-specific work outside of the engine's remit. Also the system call to get the current time is costly if done too frequently, so I'd rather drive ticks from a timer than check the time on every IO event (it is workable but not ideal.) Just FYI: I'm working on an example driver to show using the connection engine with libuv, it's very raw and doesn't have ticks yet (it will soon) but if you're curious: https://github.com/alanconway/qpid-proton/tree/libuv-driver I think your work is probably ahead of this in features, but it might be interesting. The goal is to organize a C framework so multi-threaded C applications (including the Proton C++ binding and Qpid Dispatch router) can swap out the IO platform without big modifications. > > > > -- > View this message in context: http://qpid.2158936.n2.nabble.com/Azure > -Service-Bus-receiver-timing-out-with-electron-go-binding- > tp7651057p7651625.html > Sent from the Apache Qpid developers mailing list archive at > Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
