On Fri, 23 Mar 2018, Eric Cano wrote:
> @abh3, regarding the phantom session, I extrapolated that if the client
> gets `kXR_wait` as a reply to `endsess`, it should wait and try again,
> i.e. re-issue the endsess? Would that explain completely the problem?
We narrowed down the problem to the client-side not completely
implementing the required strategy for endsess handling. Yes, the server
is asking the client to wait and retry later
> If so, it is still worrying that the link could not be terminated in
> XrdXrootdProtocol::do_Endsess() one minute after establishement, and
> that
> more than one other minute after, the initial open finally got
> delivered.
> Would this mean the retry timing is dependent on the TCP session dying
> on
> its own? Could you kill the phantom/previous connection more drastically
> ("deep six" it as you were suggesting) so we can ensure the server will
> disregard anything coming from the phantom connection? I think this is
> needed to open the possibility for aggressive retries in low latency
> environments (or simply have control of our retry timings).
Yes, I am investigating this. It's not as easy as one would think because
doing this introduces other side-effects. So, I'm proceeding with an
abundance of caution. At the moment, we believe, that implementing the
full endsess sequence in the client should alleviate the problem. That
doesn't mean you can't get a zero length file but that is no different
than the client issuing an open and then crashing. That you cannot solve
other then turning on POSC mode which comes with not insignificant
overhead.
Andy
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/673#issuecomment-375779761
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
