On 07/29/2015 02:39 PM, Tomáš Šoltys wrote:
Does this mean that for example I will set timeout to 10 seconds and
message processing in PN_TRANSFER will take 1 minute or more that
connection will eventually timeout?
Is my assumption correct?
What you set as the idle timeout determines the rate at which the remote
peer must send heartbeats (or other traffic). What the remote peer
specifies as their idle timeout determines the rate the local process
must send out heartbeats.
If you don't process the connection (call pn_transport_tick and write
out any data from the transport to the wire) sufficiently frequently
then the heartbeats won't be sent sufficiently frequently and the remote
peer may time out the connection.
Likewise, detecting the connection is idle locally involves calling
on_transport_tick sufficiently frequently. I'm not entirely sure how the
code works internall, so I don't know for example whether it would
timeout the connection if the heartbeats that had arrived on the local
socket were pumped into the transport late. I suspect that is down to
the order of processing input and calling on_transport_tick.
In generaly though, you want to ensure that you can process the
connection (do any input and output and call tick) in a timely manner,
and if you need to do any task that may prevent that, it should be done
on a separate thread (or written in such a way that it doesn't require
the thread to be blocked from any other wokr for the duration of the task).