 |
 |
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 -- Dr. Derek Feichtinger Tel: +41 56 310 47 33 AIT Group email: [log in to unmask] PSI http://people.web.psi.ch/feichtinger CH-5232 Villigen PSI