Hi Lukasz,
Thanks for explaining it. So, te Casor plugin simply wants to know if the
delete was because of a disconnect or some other reason and the plugin
wants to control post action. If so, I could do something like:
virtual void Delete(bool disc=false) {delete this;}
and substitute all delete's for Delete's and when a delete happens on a
disconnect disc will be true. This avoids other plugin writers from having
to change their code but the Castor people can write their own delete
handler. Would that solve the problem? I can see where this may very well
cause a memory leak if one is not very careful.
Andy
On Fri, 6 Dec 2013, Lukasz Janyst wrote:
> Hi Andy,
>
> the problem here is really a mismatch of architectures between Castor and XRootD. The castor-xrootd plugin always stalls the client because it needs to wait for a response from Castor. Now, if the client disconnects, the castor request needs to be explicitly aborted in order not to abuse the throttling mechanism in Castor. Would it be possible, to use something like `::Delete( reason )` instead of the destructors?
>
> Cheers,
> Lukasz
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/63#issuecomment-29973053
—
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