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).
