Jared Johnson wrote:
Hi,
I noticed in the recent 'config weirdness' thread that QP does caching
for config calls. Could anyone summarize the nature of this caching?
I've got a lot of configuration directives of various sorts stored in a
database and I'm looking at making a config plugin to handle loading
them. I'm hoping that qp's caching will help and not hinder this:
are config directives cached at all when they're retrieved on account of
a hook_config plugin, or does the hook_config plugin get called
immediately whenever qp->config() is called, bypassing the cache?
how long does the cached config last? the life of the transaction? the
life of the connection? longer?
Since Matt hasn't said anything up to now...
The intent of the code appears to be that ultimately config() will cache
the results of configuration lookups, and clear it upon receipt of a
signal. Also as part of the signal, IIRC, each of the children
processes will be "draining" their queues. I think the master process
essentially no longer passes inbound connects to them, and once each
child runs out of work, they're killed, and new ones with fresh
configurations are started.
This came out of a query from me about being able to get qpsmtpd to
reload it's configuration instead of having to restart from scratch.
The highest level config() function doesn't cache, the lower level parts
do. Without looking again, it looks as if a config hook doesn't cache,
it won't get cached. The CDB handling inside the get_qmail_config
doesn't cache for example.
