There's an ongoing investigation into some occasional failures seen on an EOS instance at cern; While that's still going on I've seen some problematic behavior in XrdCl that is probably contributing. But I think there's enough to open an issue for the specifics seen in the client so far. Consider the sequence:
```
XrdCl::File *f = new XrdCl::File();
f->Open("root://me@pmpe01:1194//f1", XrdCl::OpenFlags::Read);
f->Read(0,5,buf,bytesRead,0); // gets 5 bytes from file 'f1' ok
sleep(20); // during this time the Xrootd server on port 1194 is restarted
XrdCl::File *f2 = new XrdCl::File();
f2->Open("root://me@pmpe01:1194//pww1", XrdCl::OpenFlags::Read);
f2->Read(0,5,buf,bytesRead,0); // gets bytes from file 'pww1' ok
f2->Close();
delete f2;
sleep(330);
// during this time the default TTL (300s for dataserver) expires and connection is closed
f2 = new XrdCl::File();
f2->Open("root://me@pmpe01:1194//pww1", XrdCl::OpenFlags::Read);
f2->Read(0,5,buf,bytesRead,0); // reads bytes from 'pww1' ok
f->Read(0,5,buf,bytesRead,0); // reports no error but bytes are from 'pww1' not 'f1'
```
(In the case of the EOS problem this is probably only a contributing factor, there may be other issues. For instance there is no server-restart, unlike in the above - possibly we have a stream-timeout instead).
--
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/1942
You are receiving this because you are subscribed to this thread.
Message ID: <[log in to unmask]>
########################################################################
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
