Re: userlogging module?

On Fri, Feb 16, 2001, Robert Collins wrote:
> The MySQL acl patch provided here perviously might provide some inspiration, or even details :]

I should look at it.

> If you mean _just_ the actual write to disk bit, won't we have a terribly small helper?

Well, depends if the helper is going to log to a database.

> I don't see any benefit in breaking any more of the access log code out to a helper - why not just have a queue of pending log
> entries that are only cbLocked by the logging code. Then the logging code runs a pair of async i/o functions (similar to
> clientsendmoredata & clientwritecomplete) that call the low level async functions

It depends if the db code thats out there lets you break the db accesses
out into async chunks focused around poll/select.

If not, then you could possibly risk a stall if the sql functions don't
return immediately.

> To add in a database we write a new set of low level async functions for that db, and configure them via squid.conf.
>
> The reason I'm against the external helper is a) that the operation being effected is so trivial, and b) we already have most of an
> async framework in squid - lets use it and c) the volume of access entries is going to very high for a single helper (and to keep it
> serialised you can only have a single helper ?)

We have most of an async framework in squid, its just not used for
the disk ops (in disk.c) anymore.

Yes, I realise that its going to tax whatever method is used for
IPC as its going to be high throughput. I suggested it because
an external process(es) allows log agents to be written that
don't lend themselves towards being IO or pthreaded (eg perhaps
mysql, but I'm sure you can think of others..)

Its just an idea. :-)

Adrian

-- 
Adrian Chadd			"Romance novel?"
<adrian@creative.net.au>	 "Girl Porn."
				    - http://www.sinfest.net/d/20010202.html