In XrootD you can have any number of session from the same client and we fully support those. The only thing you should not have is phantom sessions from the same client because the client then thinks all is going well when, in fact, it’s violating it’s own rules of protecting data. Think of it as creating a thread that goes around modifying data and not trying to synchronize with it from another thread doing the same thing. The endsess request was introduced to allow the client to kill any phantom sessions that it may have introduced. Which, as Steven so well pointed out, may occur during error recovery. So, yes, it’s required that the client properly handle endsess to make this work. On the other hand, the new fixes for handling open requests will also fix this problem for most, but not all, cases. Fortunately, the ones that evade detection are not part of a HEP workflow from what I can tell.
Andy
From: murrayc3
Sent: Thursday, March 22, 2018 8:17 AM
To: xrootd/xrootd
Cc: Andrew Hanushevsky ; Mention
Subject: Re: [xrootd/xrootd] C++ API to XRootD should allow the "open file" retry logic to be turned off (#673)
From what I have seen so far in these discussions, the current XRootD protocol relies on only one session being active per client at a time. If this rule is broken then a brand new XRootD protocol would need to be defined which could use of course use Lamport Timestamps.
Assuming that the XRootD protocol will not be changed any time soon then keeping only one session active at a time per client must be enforced at all costs. This means the XRootD client must handle a kXR_wait response to an kXR_endsess request. Have I simplified this too far and am missing something?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
—
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: In XrootD you can have any number of session from the same client and we fully support those. The only thing you should not have is phantom sessions from the same client because the client then thinks all is going well when, in fact, it’s violating it’s own rules of protecting data. Think of it as creating a thread that goes around modifying data and not trying to synchronize with it from another thread doing the same thing. The endsess request was introduced to allow the client to kill any phantom sessions that it may have introduced. Which, as Steven so well pointed out, may occur during error recovery. So, yes, it’s required that the client properly handle endsess to make this work. On the other hand, the new fixes for handling open requests will also fix this problem for most, but not all, cases. Fortunately, the ones that evade detection are not part of a HEP workflow from what I can tell.\n\nAndy\n\nFrom: murrayc3 \nSent: Thursday, March 22, 2018 8:17 AM\nTo: xrootd/xrootd \nCc: Andrew Hanushevsky ; Mention \nSubject: Re: [xrootd/xrootd] C++ API to XRootD should allow the \"open file\" retry logic to be turned off (#673)\n\nFrom what I have seen so far in these discussions, the current XRootD protocol relies on only one session being active per client at a time. If this rule is broken then a brand new XRootD protocol would need to be defined which could use of course use Lamport Timestamps.\n\nAssuming that the XRootD protocol will not be changed any time soon then keeping only one session active at a time per client must be enforced at all costs. This means the XRootD client must handle a kXR_wait response to an kXR_endsess request. Have I simplified this too far and am missing something?\n\n—\nYou are receiving this because you were mentioned.\nReply to this email directly, view it on GitHub, or mute the thread.\n"}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/673#issuecomment-375461815"}}}
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
