> Am 20.06.2017 um 14:35 schrieb Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com>: > > It might cause I/O overhead compared with socache_shmcb, but it might be a > good solution > for those who want to have persisted OCSP responses. Other people might > priorize > a distributed cache like dc or memcache. So I like the idea of just staying > with the current approach to define the socache provider used for caching. > Who knows? Maybe someone writes a socache_staggered that allows to go through > several > socache providers one after another in case of a cache miss? That would allow > to have > a shmcb first and a dbm second.
I agree to the re-use and the more flexible architecture we already have in place here. The only bone I have with this is that it has "only" cache semantics and is not a store. Sure, we can document that an admin should make the cache "large enough", but it's not totally under his control as the size of the answers can vary. If we update the answers regularly by watchdog, we should remove the request trigger during connection setup (e.g. complexity, race conditions). A too small cache could really hurt. OTOH: is dbm really size limited? Maybe it is not. Then this would be my preference. >> >> As an alternative, use of mod_watchdog offers advantages here. If we >> have only one thread (for all or for a particular certificate) that >> writes the cache in a server (all processes), it becomes easy to use the >> file system, I think. Write per tmpfile+rename should be good enough and >> it should no longer need a global mutex. Server names are distinct and >> make for an easy directory tree. >> >> The question then is if mod_watchdog jobs still have privileges or if >> those files have common ownership and if that is a problem. >> >> Does this makes sense or am I insane? > > I guess this is all solvable, but as stated above I am in favor of just using > the > socache API for that and let our requirements be solved by an appropriate > socache > provider. "staggered" cache with store semantics would be cool. -Stefan
