Re: [naviserver-devel] RFE: Expanding ns_log/ns_logctl

[Stephen D. <sd...@gm...>]

On 6/25/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 25.06.2006 um 12:48 schrieb Stephen Deasey:
>
> > What happens if you push but don't pop, maybe an uncaught error?
>
> I was also thinking about:
>
>    ns_logctl register callback ?arg...?
>    ns_logctl unregister callback
>
> This way the push/pop is avoided and the problem of non-symetric
> usage is gone, as callbacks will be added/removed to/from a list
> not a stack.
>
> The callbacks themselves will be called in succession by the underlying
> implementation. The very first (default, always present) callback will
> be a call to write() as in the current implementation. This guarantees
> that log entries will be written into the log file, as today.
> Other callbacks may be called in FIFO or LIFO order (there are some
> thoughts about that below...)
>
> >
> > The very first change in aolserver cvs after being opened was to
> > remove the modlog api. Like most logging implementations, it took both
> > a facility and  a level.  Ns_Log only takes a level.
> >
> > How about adding a 'facility' arg back?
>
> Would that mean ns_log will be something like:
>
>     ns_log ?-facility whatever? severity arg ?arg ...?
>
> ??
>
> Actually, at the moment I was not thinking about facilities although
> it might
> be considered as well. My primary motivation behind this is to get
> better
> *organization* of the existing log information (severity, message,
> timestamp
> process-id/thread-id).
>
> At the moment we have everything line-wise in one log file. This is
> good as
> you always know where to look, and there is a time-related order
> there as well.
> But, disadvantage is: one can easily get lost if you have 100'000 of
> lines of
> log info generated by different modules all doing logs for the same
> "job".
> By adding some additional log "sinks" I can channel log information into
> appropriate "per-job" log files. This retains the global log file but
> adds
> more *order* by separating "job-related" logs into corresponding per-
> job files.
>
> For example:
>
>    proc joblog {level timestamp message jobId} {...}
>    set id the_job_id_or_handle
>    ns_logctl register joblog $id
>
> So when somebody says:
>
>    ns_log info "This is the info"
>
> the log facility will emit a log line into the log file
> (as it does now), but will in addition call:
>
>     joblog info 1151234419:0000000 "This is the Info=10"
> the_job_id_or_handle
>
> Depending on the passed user argument(s) (in the above case
> the_job_id_or_handle) the "joblog" will know what to do, i.e.
> where and how to produce log entry.
> The "timestamp" argument will include both seconds and microseconds
> (we already have Tcl_Obj type for that).
>
> When the callback is not needed any more, it can be removed
> by calling:
>
>    ns_logctl unregister joblog
>
> One can have any number of callbacks registered. All of them
> will be entered in a list and invoked one after another
> with the same level, timestamp and message arguments, but with
> different user argument(s).
>
> One additional thing we MAY do is to invent a callback return
> value to signalize "continue" or "break" in the similar sense
> as filters are doing. This way any callback can forbid lower
> level callbacks to be invoked. This is just an idea and it
> needs careful thinking though. For example: what does this mean
> for the standard logfile sink? If an late callback returns break
> would that cut-off the standard log sink or just registered
> callbacks? Of course, this will require us to defined order of
> invocation i.e. LIFO or FIFO as well...
>
> I hope I managed to convey the *general* idea to you...


Got it.

It might still be a good idea to add 'facility' as a parameter.  e.g.
your registering a callback and passing an arg 'id'.  Your callback is
distinguishing what to do depending on the arg -- it get's called no
matter what the level is.

If you add facility, you could:

  ns_logctl register $facility $priority joblog ?arg ...?

The filtering would be done by the server, rather than the callback.
You're focusing on sinks here, but you need a way to distinguish what
goes where, and facility levels seem like such a standard thing.  It
would enable you to turn on verbose logging for just one area of code,
which would reduce log spam.

Take a look at log4j by the apache project.  This is very popular and
seems to have inspired a lot of imitators such as log4py, log4c etc.
Maybe log4c has a better API than the old Ns_ModLog stuff.