Indeed, the server closes all files opened by that connection. So, the
behaviour you described would be the nehaviour that is wanted to prevent
any memory leaks because the application thinks it cannot safely delete
the file object. The only thing you should keep in mind is the following
edge case:
1) A I/O was started,
2) The connection was lost (for whatever reason),
3) The outstanding I/O was queued for retry. Since yje I/O is queued the
connection has not yet been re-established,
4) The application issues a close.
5) If you ignore the queue I/O and return successbecause the connection is
gone then you will get a SEGV whe the queued I/O resumes.
So, it would seem you also need to be sensitive to the fact of whether or
not there is still something queued for that connection and return failure
on the close as would be the normally be the case.
On Tue, 20 Apr 2021, simonmichal wrote:
> Regarding the `invalid session` error on close, this could happen due to a TTL or stream timeout. In case of TTL the connection is being closed gracefully. In case of a stream timeout the server will get the `kXR_endsess` request on reconnect so it will also terminate the original connection. Hence, we know that in both cases the server is aware that the connection has been dropped. Now, as far as I understand, when a connection is shutdown the server also closes all files associated with that connection, @abh is this correct? If yes, I think we can safely say that the file has been actually closed.
>
> Now, currently when there is a `errInvalidSession` error on close and the file is in read-only mode, the file state is set to `Closed`, however the `errInvalidSession` is propagated to the user:
> https://github.com/xrootd/xrootd/blob/e810e31908b49bbb8445c91118ae1b38c5577aa8/src/XrdCl/XrdClFileStateHandler.cc#L995-L1002
>
> If the answer to my question is yes, then I would say we could relax this and assume the file is successful closed in general (and not only for read-only files), furthermore we can return success to the user instead of returning `errInvalidSession`.
>
> @abh3 : let me know your thoughts!
>
>
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1437#issuecomment-823235413
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1437#issuecomment-823521225",
"url": "https://github.com/xrootd/xrootd/issues/1437#issuecomment-823521225",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
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
