 |
 |
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