httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: non-forking wish list
Date Thu, 08 Jun 1995 16:31:15 GMT
> Randy said...
> > My thoughts are that we should _not_ be creating another process, 
> > but be giving the responsibility to the parent process
> 
> by default, I agree - no extra process for logging, the parent does
> absolutely nothing now in 0.7.x (except for handling SIGCHLD, SIGHUP..),
> so it's ready to take on a new job.
> 
> as an option, the user should be allowed to override the Apache parent
> logging, in favor of an external process, which the children could talk
> to via a socket.
> 
> > and enabling the parent to be able to write to a FIFO.  Can we 
> > agree on that?
> 
> FIFO - as in, first child to tell it to log something, gets logged  ?

FIFO - as in named pipe. One concern that RST raised is giving
the parent too much to do.  I agree with that concern. I think
that giving the parent the responsibility to manage the
transaction log for each child should not be too much of a load.
The "write to FIFO" would mean that it would simply dump that
information down the pipe *after* the child sends the "logit"
request back to the parent.

I still believe that any hostname lookups, formating, logging to
database, etc. should be handled by an external process reading from
that pipe. This would also make it relatively easy to configure a
CLF format and write it to a flat file for backward
compatibility.

WRT the suggestion of the status monitor and an "internal"
protocol to request that information, it would make sense
to have the children using this same protocol to exchange the
logging information, no?

If this is the way to design this, can one of you gurus suggest a
networking mechanism to focus on to accomplish this? This may be
one of those features that is not supported on braindead
UNIX-like systems. Thoughts? IPC?

> I still think the children should send pieces of loggable info, as 
> and when they feel like, and in no particular order. This'll make
> configuration of logging *much* easier in the long term.
> IMO, CLF II should define how the info is passed... preferably in
> some abbreviated form..

I agree with this model. I would however like to make the issue
of whether or not to send headers configureable. Should be easy
to toggle.

> 
> URL: /foo/bar/
> VHOST: www.apache.disorg
> HTTP: 1.0
> CL: client.some.where.com
> UA: Mozilla;2.0
> REF: http://another.edu/links/com_sites.html
> MTH: GET
> QS: query+string
> STAT: 200
> LEN: 1234                                (content-length sent)
> STIME: 1789364                           (time request received)
> ETIME: 1789366                           ( "     "     completed)
> AUSER: fred
> APASS: fredsPassword
> etc.


Mime
View raw message