On Thu, 1 Oct 2009, Rainer Gerhards wrote: >> -----Original Message----- >> On Thu, 1 Oct 2009, Rainer Gerhards wrote: >> >>> I have now reviewed the discussion in depth. Many thanks >> for all the good >>> thoughts. >>> >>> I will now first begin to move the name resolution calls to >> the "backend" >>> threads (away from the inputs). However, I will create an >> option that the >>> name resolution may be done before enqueing the message, >> which may be used by >>> some folks for whatever reason (plus, it is trivially to >> do). I also think I >>> will leave in the capability that inputs do the name >> resolution themselfs, at >>> least if they prefer. For example, imuxsock always has the >> local host as >>> input, so it makes limited sense to do name resolution >> calls for messages >>> received from that input. Similarly, imtcp uses the name >> that was (once) >>> obtained when the session was created (btw, this is also >> some expiry-less >>> "name resolution", but I think here it is even harder to >> argue against it >>> ;)). >> >> on note on this, if you can delay the resolution to the point where >> something actually accesses the property that uses the name >> you may be >> able to skip doing name resolution entirely in many cases. > > This I plan to do, but in the TCP case I think it probably is better to do a > name resolution once per *session* even if the name may never be used. > Typically, there are many messages in a session and the overhead if the one > name lookup does not really matter. At least this is my current thinking.
no problem with filling it out earlier if the info happens to be available (or in the case of thinks like TCP, RELP, etc where it really is static). I'm thinking of things like my central server that receives the aggregated feed from several relays. everything that it does is based on the name in the log, and since the logs come from other rsyslog relay boxes, those boxes will have cleaned things up, so there is never (outside of debugging) a need for that central box to do _any_ lookups, no matter how fast they end up being. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
