In article <35D855E5.DD8C036F@terranova.net> you wrote:
>[...]
> Also, I just grabbed 1.3.1/1.22 and was wondering how gcache was doing
> stability-wise.
> It sped things up considerably when I tried it last with 1.2.6/1.17 but
> unfortunately I managed to make gcache dump all over itself too easily
> which appeared to render the server deaf and dumb.
> I see a couple gcache problems fixed in 1.3.1/1.20 (do cleanup before
> starting gcache, make it die when httpsd dies) but haven't heard
> anything from the list or from CHANGES.SSL about its actual usability
> lately.
> In fact the last major thing I remember hearing about gcache is how to
> disable it ;)
The gcache stuff worked fine for me in Apache-SSL 1.22 and mod_ssl
2.0.3-1.3.1, at least under FreeBSD 2.2.6 and SSLeay 0.9.0b.
(Perhaps Off-Topic:) But it's true that the gcache stuff is a little bit
annoying, especially because another process is running which means more
internal fiddling with child processes. That's why I currently thinking about
replacing the complete gache stuff with a DBM file on disk for mod_ssl 2.1.x.
That's similar to what Stronghold does. It looks more reasonable to me than an
extra stand-alone process running parallel. Or are there any security reasons
why the session cache should not stay on disk? Even when there are security
reasons for disk-storage then similar ones also exist for the in-core-storage.
Because one can attach a debugger to the gcache process to rip information the
same way one can lookup keys in a DBM file (ok, DBM is easier, but the
principle is the same). Opinions?
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com