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, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #673: \n\nOn Fri, 23 Mar 2018, Eric Cano wrote:\n\n\u003e @abh3, regarding the phantom session, I extrapolated that if the client \n\u003e gets `kXR_wait` as a reply to `endsess`, it should wait and try again, \n\u003e i.e. re-issue the endsess? Would that explain completely the problem?\nWe narrowed down the problem to the client-side not completely \nimplementing the required strategy for endsess handling. Yes, the server \nis asking the client to wait and retry later\n\n\u003e If so, it is still worrying that the link could not be terminated in \n\u003e XrdXrootdProtocol::do_Endsess() one minute after establishement, and \n\u003e that \n\u003e more than one other minute after, the initial open finally got \n\u003e delivered. \n\u003e Would this mean the retry timing is dependent on the TCP session dying \n\u003e on \n\u003e its own? Could you kill the phantom/previous connection more drastically \n\u003e (\"deep six\" it as you were suggesting) so we can ensure the server will \n\u003e disregard anything coming from the phantom connection? I think this is \n\u003e needed to open the possibility for aggressive retries in low latency \n\u003e environments (or simply have control of our retry timings).\nYes, I am investigating this. It's not as easy as one would think because \ndoing this introduces other side-effects. So, I'm proceeding with an \nabundance of caution. At the moment, we believe, that implementing the \nfull endsess sequence in the client should alleviate the problem. That \ndoesn't mean you can't get a zero length file but that is no different \nthan the client issuing an open and then crashing. That you cannot solve \nother then turning on POSC mode which comes with not insignificant \noverhead.\n\nAndy\n"}],"action":{"name":"View Issue","url":"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
