<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Mar 28, 2019 at 4:12 PM Gordon Sim <<a href="mailto:gsim@redhat.com">gsim@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/03/2019 12:27 pm, Bob Claerhout wrote:<br>
> Hi Gordon,<br>
> <br>
> I'm sorry for the delay.<br>
> You can find the extra logging in a wetransfer: <a href="https://we.tl/t-ych9qXsceF" rel="noreferrer" target="_blank">https://we.tl/t-ych9qXsceF</a><br>
<br>
Thanks! The logs show the broker specifies an idle timeout of 2.5 <br>
seconds. The protocol trace does not contain timestamps (enabling <br>
tracing in the router log as opposed to PN_TRACE_FRM would give the <br>
timestamps), so it is hard to be completely certain, it does look like <br>
the router is indeed not sending heartbeats as expected at the point the <br>
connections is ended (based on the closest log entries that do have <br>
timestamps, and on the heartbeat from broker to router).<br>
<br></blockquote><div><br></div><div>Hmm, its strange since the connector sets it to 5 seconds by default. Is the reporting accurate or is there a potential flaw in proton-j configuration? Looking at the source code of Artemis it should be setting transport.setIdleTimeout(5000) <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The connection prior to closing seems to have been active for nearly 5 <br>
days (2019-03-22 11:14 to 2019-03-27 03:40) without issue. There is only <br>
one other occurrence of a broker timing out a connection to the router. <br>
It is for a different broker, and the connection there lasted from <br>
2019-03-22 11:14 to 2019-03-23 17:20 (again the evidence suggests the <br>
broker was within its rights to close the connection).<br>
<br>
My suggestion would be to increase that idle-timeout a little (I believe <br>
there is an upcoming fix to enmasse to allow this to be done in config), <br>
but also for clients to be able to handle the detach that a broker <br>
disconnection may cause.<br>
<br></blockquote><div><br></div><div>PR has been merged:<a href="https://github.com/EnMasseProject/enmasse/pull/2536">https://github.com/EnMasseProject/enmasse/pull/2536</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have no obvious explanation for *why* the router did not respond in <br>
time. Of the 44 connections for which traces are logged in a 10 second <br>
period around the time of the last timeout, only two were doing anything <br>
other than heartbeats. Of the rest 29 sent at least one heartbeat.<br>
<br></blockquote><div><br></div><div>Best regards,</div><div><br></div><div>Ulf<br></div><div> </div></div></div></div>