Hi Derek,

   coming days we I'll check in a new feature in PROOF to allow user file 
upload. It uses xrootd protocol via the TFileMerger class of Andreas. Using 
this mechanism the redirector will place the files nicely distributed over 
the available xrootd servers. As soon as it is checked in (tomorrow or 
tuesday) please check it and provide us feedback.

Cheers, Fons.

Derek Feichtinger wrote:
> Hi, Fabrizio
> I best describe, what context led me to the initial question:
> I'm just preparing a little script to produce and distribute files over a 
> range of hosts running xrootd (for PROOF tests). If a host cannot be 
> contacted (e.g. nox xrootd running there) I do not want long timeouts, so the 
> script should just remove the host from the list after a few seconds and try 
> to place the file on the next host. But I do not want these timeout settings 
> to apply to other file accesses (I can easily live with a host that is down, 
> but not with a critical file that needs to be read). I do not want to use a 
> redirector setup for this, because I want to control where a file is placed.
> Cheers,
> Derek
> On Friday 10 March 2006 14.53, Fabrizio Furano wrote:
>> Hi all,
>>   well, right now I am unable to see a clear reason for this. Let's
>> discuss it. Those values were supposed to be in general "arbitrary", in
>> the sense that normally it has no sense at all to modify e.g., a timeout
>> value. It is 60 sec, but 90 or 120 makes very little difference if you
>> are using the software in a plain way.
>>   The direction I'd like to look at is a direction where one has no need
>> to tweak with strange parameters to have a nice xrootd experience.
>> The dreamable solution is that the client manages its "crucial"
>> parameters by itself (e.g. the cache block size or the number of
>> parallel streams). For instance, we were recently planning the
>> implementation of the multistream xfers, and we totally agreed on the
>> fact that the client has to calculate (and adjust) internally this
>> parameter with no need for intervention. Why would one want to modify a
>> parameter that works?
>> The consequence of your proposal is instead a multiplication of the
>> parameters, so I am a bit puzzled. Can you give some use cases where
>> such a functionality is mandatory? Where for mandatory I intend that a
>> *real* test fails (or performs poorly) with value X=default and succeeds
>> with value Y. Right now I am unable to wonder such a situation.
>>   The other direction I am looking at is the reduction of the global
>> overhead. I will work heavily on that, since there are many aspects that
>> are worth an optimization.
>> Right now the most frequently used parameters are read from the env only
>> in the ctor, in order to avoid a mess of accesses to string-based hash
>> tables. Every time I find a parameter which is read too many times per
>> single transaction, I wonder if I can move it to the ctor (and loose the
>> possibility to change it at runtime). Asking for the ability of
>> generically modifying param values during the use of a single instance
>> of the client (or a connection) would raise a lot this overhead for sure.
>> Fabrizio
>> Derek Feichtinger wrote:
>>> Hi, Gerri and Fabrizio
>>>> Yes, as it is now TXNetFile allows only one set of globally-set config
>>>> options.
>>>> I remember a brief discussion we had Fabrizio and I once on this, but
>>>> then nothing has been done.
>>>> As this may be relevant also for  'xrdcp',  perhaps  we should introduce
>>>> the possibility to define 'per host' rules in a config file checked by
>>>> XrdClient,
>>>> making use of the existing 'if-then' infrastructure used for server
>>>> directives.
>>>> What do you think?
>>> That sounds good. But even on top of that it would be nice to be able to
>>> set the options per connection. Maybe the logic of my program wants to
>>> check fast, whether it can access certain non critical files, but still I
>>> want to have more stringent settings for critical files. If I use
>>> threads, the gEnv way would force me to introduce mutexes (by the way:
>>> what happens in the case of async connections, when I change the options
>>> while they are still in process?).
>>> Cheers,
>>> Derek

Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: [log in to unmask]              Phone: +41 22 7679248
WWW:           Fax:   +41 22 7669640