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.
Derek Feichtinger wrote:
> Hi, Gerri and Fabrizio
>> Yes, as it is now TXNetFile allows only one set of globally-set config
>> 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
>> making use of the existing 'if-then' infrastructure used for server
>> 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