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
> 

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

Reply via email to