Hi, Have you proven that the server is seeing ACKs and things from the client in the connections that are dropping? I don't think this is some kind of delayed or coalesced ACK thing, but maybe.
Given that it appears that the server is the one timing out the connection, that leads me to believe that perhaps it thinks the connection has been abandoned. If we had a reproducible case of this, we could debug it, but as it stands, you are the only source of diagnostic data for this issue. -dre Sent from my iPhone > On Feb 13, 2015, at 10:15 PM, Jacques Distler <dist...@golem.ph.utexas.edu> > wrote: > > >> On Feb 13, 2015, at 5:05 PM, Jacques Distler <dist...@golem.ph.utexas.edu> >> wrote: >> Nope. That doesn't return anything in the log. >> >> The only error is >> >> 2015-02-13 16:57:16-0600 [-] [caldav-3] [-] [twext.web2.channel.http#error] >> Connection aborted - took too long to close: IPv4Address(TCP, >> '128.83.114.6│3', 63006) >> >> >> Which means that _abortTimeout() is being called from >> requestWriteFinished(), rather than from timeoutConnection(). > > Indeed, one can verify this by changing the value of the closeTimeOut > parameter at line 890, and noticing that the time it takes for the connection > to close, as seen by the client, changes accordingly. > > > _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
