Hi Brian,

Crap. We try not to change function signatures like that. What class did 
this occur in?

Andy

On Wed, 12 Jan 2011, Brian Bockelman wrote:

>
> Ah great.  In that case, I just need to dig out the time to figure this out.
>
> Side note: are there any defines which would allow us to determine the version of xrootd at compile-time?  One issue with v3.0 versus the version we currently used is a function signature has changed for StageIn, causing runtime issues.
>
> Brian
>
> On Jan 12, 2011, at 3:33 AM, Lukasz Janyst wrote:
>
>> If your TFile object is deleted before the fork it should be fine to
>> just install the fork handlers. The destructors call everything that
>> is required for this to work.
>>
>>   Lukasz
>>
>> On Wed, Jan 12, 2011 at 9:13 AM, Lukasz Janyst <[log in to unmask]> wrote:
>>> Hi Brian,
>>>
>>>   the disconnection stuff is exactly one of the things that I still
>>> have to work on. For some reason that I yet have to discover the
>>> Disconnect method is not called on Close, but still tries to commit
>>> some requests... Disconnect cannot be called from the fork handlers
>>> because they know only about the global ConnectionManager which
>>> handles Physical and Logical connections, the XrdClient object however
>>> has it's own Connection object which combines the two and is not
>>> registered to the ConnectionManager.
>>>
>>> Cheers,
>>>   Lukasz
>>>
>>>
>>>
>>> On Tue, Jan 11, 2011 at 8:38 PM, Brian Bockelman <[log in to unmask]> wrote:
>>>> Hi Lukasz,
>>>>
>>>> Thanks.  I have a plethora of teleconferences to attend today, but hopefully will hit this sometime in the next 24 hours.
>>>>
>>>> Why do we have to both install the fork handlers and disconnect the client connections?  Can't the latter just be done inside the fork handler (or maybe I'm asking the question too soon, and that's what prototype #2 does...)?
>>>>
>>>> My issue is that, in the current set of abstractions, we have no way to distinguish "please close the file and disconnect the client" and "please close the file".  The forking and the I/O handling code is done in two completely separate parts of the CMS framework.  Further, I'm not even sure of the lifetime of the file handle; it may be the TFile object is long gone by time we decide to fork.
>>>>
>>>> Brian
>>>>
>>>> On Jan 11, 2011, at 11:54 AM, Lukasz Janyst wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>>   I attach the patch for the first prototype. It hasn't been tested
>>>>> much (apart from the most simplest case) so it may cause your stuff to
>>>>> crash. It definitely still needs some work, but it would be helpful if
>>>>> you could try it out and give me some feedback.
>>>>>
>>>>>   Some remarks:
>>>>>
>>>>>   * at the initialization time you should call once and only once:
>>>>> XrdClientEnv::InstallForkHandlers()
>>>>>   * before forking, when you're done with your reading you should say:
>>>>>
>>>>>  cl.Close();
>>>>>  cl.GetClientConn()->Disconnect( FALSE );
>>>>>
>>>>>   for all your files opened with xroot (cl is an instance of the
>>>>> XrdClient class).
>>>>>
>>>>> Cheers,
>>>>>   Lukasz
>>>>>
>>>>> On Tue, Dec 14, 2010 at 8:41 AM, Dirk Duellmann <[log in to unmask]> wrote:
>>>>>> Lukasz should be back at work today and we'll get back to this now. I'm sure he will fold this into
>>>>>> the plan for the next release which we will start to discuss soon. As Andy said, there are also other
>>>>>> quite  high priority items like a pre-release functional and stress test and changes around a simplification
>>>>>> of the currently  quite protocol dependent handling of the lower parts of root which we started to discuss
>>>>>> with the root team. If we have a little bit of time to sort the proposed changes by effort, risk and priority then
>>>>>> we can probably avoid surprises late in the release procedure. We haven't really discussed this much
>>>>>> between all the developers on the xroot side, but I personally would vote for having a short page with the
>>>>>> planned items documenting their state so that people can follow whats coming. For castor we use
>>>>>> a one page list with one line per savannah bug or enhancement request which has a state running
>>>>>> from "planned" through "developed", "tested" to "committed (for a release)".
>>>>>> (see eg https://twiki.cern.ch/twiki/bin/view/DataManagement/CastorReleasePlan21100 )
>>>>>> Of course not all of the fields apply to xroot directly (eg schema change -> protocol change, no
>>>>>> SQL hotfixes, etc..)
>>>>>>
>>>>>> This doesn't really solve the technical issues directly but helps all people involved to keep an overview
>>>>>> of all items. The first step could be to really start using savannah for all candidate items now to track the
>>>>>> technical details a bit more consistently than just by email.
>>>>>>
>>>>>>        Cheers, Dirk
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 14 Dec 2010, at 01:53, Andrew Hanushevsky wrote:
>>>>>>
>>>>>>> Hi Pete,
>>>>>>>
>>>>>>> It's really up to Lukasz as he's intimately familiar with the code and whatever he does has to be compatible with other changes he wants to make.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On Tue, 14 Dec 2010, Peter Elmer wrote:
>>>>>>>
>>>>>>>> Hi Andy,
>>>>>>>>
>>>>>>>> On Mon, Dec 13, 2010 at 06:05:00PM -0600, Brian Bockelman wrote:
>>>>>>>>> On Dec 13, 2010, at 5:57 PM, Andrew Hanushevsky wrote:
>>>>>>>>>> I was not suggesting that this is not a good thing to do or
>>>>>>>>> that you give it up. I was only suggesting that perhaps by re-organizing
>>>>>>>>> the CMS code it would make it easier to do this without problems.
>>>>>>>>> In any case, Lukasz is not feeling well at the moment so there is
>>>>>>>>> no status change. I'm sure he'll speak up when there is.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I didn't know Lukasz was sick, but I suspected everyone at least
>>>>>>>>> needed a rest after the v3 rush :).  Thanks for the status update,
>>>>>>>>> we'll roll it into our plans and let you know if things become more
>>>>>>>>> urgent.  There are several other moving pieces to this project, so
>>>>>>>>> a patch by end-of-January would still be in time.
>>>>>>>>
>>>>>>>> Actually, having it sooner than that would be useful for testing.
>>>>>>>> When you can think about this?
>>>>>>>>
>>>>>>>>                                  Pete
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
>>>>>>>> Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>
>>>>>>
>>>>>>
>>>>> <fork.patch>
>>>>
>>>>
>>>
>
>