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.


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

Dr. Derek Feichtinger                   Tel:   +41 56 310 47 33
AIT Group                               email: [log in to unmask]
CH-5232 Villigen PSI