Hi Dirk,

Sad to say it took me 7 months, but I think I have the issue fixed! In the end, it wasn't a mysterious threading or memory management issue - a simple logic mistake exists in the new client when reading ReadV requests.

Any user of the new client sufficiently unlucky should be able to trigger it - all that needs to be done is perform ReadV (no threading necessary!). In our tests (which "encourage" the race condition because things are read over the wide area), about 10% of jobs die due to it.

IMHO, this definitely needs to be backported to the stable series.

Brian

On Apr 24, 2014, at 2:54 AM, xrootd-dev <[log in to unmask]> wrote:

> Hi Brian,
>
> Lukasz is probably still traveling - let me know if we need someone to look at this before he is back on May 5th.
>
>
> Cheers, Dirk
>
> On 24 Apr 2014, at 05:42, Brian Bockelman <[log in to unmask]> wrote:
>
> > Hi @ljanyst -
> >
> > Any further thoughts on this one? I'm still stumped and large-scale testing hasn't really revealed any more clues.
> >
> > Currently, this is the last thing standing in the way from using the new client in CMS.
> >
> > Brian
> >
> > —
> > Reply to this email directly or view it on GitHub.
> >
> >
> > 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
> >
> —
> Reply to this email directly or view it on GitHub.
>


Reply to this email directly or view it on GitHub.



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