You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2003/03/20 17:45:39 UTC

[PATCH] remove shmht from mod_ssl

Has anyone done any testing of shmht in 2.0? It quickly stops caching
new sessions for me using Geoff Thorpe's swamp tool.  If anyone does
want to put effort into getting it working, I've attached a patch which
contains some fixes: the conversion to the RMM code was not finished.

I don't really see any point in putting any effort into the shmht code;  
shmcb has been the session cache of choice for a while (and it works
fine in 2.0 by my testing).  I've attached a second patch which removes
shmht completely, which is the patch I'd recommend.  The files
ssl_util_table.[ch] and ssl_scache_shmht.c can be removed after applying
this patch.

Regards,

joe

Re: [PATCH] remove shmht from mod_ssl

Posted by Bill Stoddard <bi...@wstoddard.com>.
Joe Orton wrote:
> Has anyone done any testing of shmht in 2.0? It quickly stops caching
> new sessions for me using Geoff Thorpe's swamp tool.  If anyone does
> want to put effort into getting it working, I've attached a patch which
> contains some fixes: the conversion to the RMM code was not finished.
> 
> I don't really see any point in putting any effort into the shmht code;  
> shmcb has been the session cache of choice for a while (and it works
> fine in 2.0 by my testing).  I've attached a second patch which removes
> shmht completely, which is the patch I'd recommend.  The files
> ssl_util_table.[ch] and ssl_scache_shmht.c can be removed after applying
> this patch.
> 
> Regards,
> 
> joe

+1

Code in the server that does not work should be removed or fixed, not 
left laying around.

Bill


Re: [PATCH] remove shmht from mod_ssl

Posted by Geoff Thorpe <ge...@geoffthorpe.net>.
Hi there,

* William A. Rowe, Jr. (wrowe@rowe-clan.net) wrote:
> At 10:45 AM 3/20/2003, you wrote:
> >Has anyone done any testing of shmht in 2.0? It quickly stops caching
> >new sessions for me using Geoff Thorpe's swamp tool.  If anyone does
> >want to put effort into getting it working, I've attached a patch which
> >contains some fixes: the conversion to the RMM code was not finished.
> 
> +1, as long as this code remains in the tree, it's good for us to have
> the very best code available.

Might I suggest that anyone interested in shmcb get in contact and we
talk about cleaning that up first? As was discussed recently in another
thread, there seems to be some concern about the use of the
alignment-fudging accessor functions I put in there, and rather than
trying to align shmcb's geometry (which is what is suggested in the
STATUS file) I suggested that I rejig the code itself to blast the
header structures on and off the shm segment directly - simplifying the
code, removing alignment hassles, and (I believe) not affecting
performance.

For my part, I'm happy to do this and I would *certainly* feel better
about doing it prior to shmht being unplugged from apache altogether.
Call me paranoid if you like. Anyone following openssl lists will know
why I've been a bit distracted of late. Apache's autoconf hooks for
openssl was my first priority up until it was recently committed, and my
second priority in turn is to submit distcache(.org) glue code for
2.1-dev too. In short, I'm ready to roll on shmcb work once the
distcache hooks are sorted out - and this (BTW) may also be wise before
culling shmht, because it provides another high-performance (if I might
be so bold to say) cache alternative to shmcb.

> I don't necessarily disagree for 2.1-dev, but we've sort of concurred that
> users shouldn't have to switch modules or configuration significantly in
> a given minor version (e.g. 2.0).  Now I'm not arguing that's it's very
> unlikely a user successfully used shmht.c, but as a matter of principle,
> we shouldn't drop this away from 2.0.

I agree, for the reasons you stated as well as the reason I mentioned
above. There were lingering reports IIRC that shmcb was "broken", and in
all my dealings with shmcb since writing it, this has generally meant
"gcc has found another way on another platform to butcher the 'safe'
accessor functions". All the more reason to think about getting the
shmcb code more robust against such issues before pulling the plug on
shmht.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/


Re: [PATCH] remove shmht from mod_ssl

Posted by Joe Orton <jo...@redhat.com>.
On Thu, Mar 20, 2003 at 12:22:17PM -0600, William Rowe wrote:
> At 10:45 AM 3/20/2003, you wrote:
> >I don't really see any point in putting any effort into the shmht code;  
> >shmcb has been the session cache of choice for a while (and it works
> >fine in 2.0 by my testing).  I've attached a second patch which removes
> >shmht completely, which is the patch I'd recommend.  The files
> >ssl_util_table.[ch] and ssl_scache_shmht.c can be removed after applying
> >this patch.
> 
> I don't necessarily disagree for 2.1-dev, but we've sort of concurred that
> users shouldn't have to switch modules or configuration significantly in
> a given minor version (e.g. 2.0).  Now I'm not arguing that's it's very
> unlikely a user successfully used shmht.c, but as a matter of principle,
> we shouldn't drop this away from 2.0.

The patch I posted doesn't require users to change anything: if they had
configured use of shmht, they'll automatically get shmcb instead on
upgrading. (A warning would probably wise with that too I guess)

Regards,

joe

Re: [PATCH] remove shmht from mod_ssl

Posted by Jeff Trawick <tr...@attglobal.net>.
William A. Rowe, Jr. wrote:
> At 10:45 AM 3/20/2003, you wrote:

>>I don't really see any point in putting any effort into the shmht code;  
>>shmcb has been the session cache of choice for a while (and it works
>>fine in 2.0 by my testing).  I've attached a second patch which removes
>>shmht completely, which is the patch I'd recommend.  The files
>>ssl_util_table.[ch] and ssl_scache_shmht.c can be removed after applying
>>this patch.
> 
> 
> I don't necessarily disagree for 2.1-dev, but we've sort of concurred that
> users shouldn't have to switch modules or configuration significantly in
> a given minor version (e.g. 2.0).  Now I'm not arguing that's it's very
> unlikely a user successfully used shmht.c, but as a matter of principle,
> we shouldn't drop this away from 2.0.

If shmht is clearly broken (i.e., we can't expect that it would have 
worked properly thus far in 2.0 releases) and shmcb is really the 
session cache of choice, I'm all for ripping out shmht from 2.0 ASAP to 
prevent user confusion rather than putting in some bandaids that don't 
really make it work.


Re: [PATCH] remove shmht from mod_ssl

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:45 AM 3/20/2003, you wrote:
>Has anyone done any testing of shmht in 2.0? It quickly stops caching
>new sessions for me using Geoff Thorpe's swamp tool.  If anyone does
>want to put effort into getting it working, I've attached a patch which
>contains some fixes: the conversion to the RMM code was not finished.

+1, as long as this code remains in the tree, it's good for us to have
the very best code available.

>I don't really see any point in putting any effort into the shmht code;  
>shmcb has been the session cache of choice for a while (and it works
>fine in 2.0 by my testing).  I've attached a second patch which removes
>shmht completely, which is the patch I'd recommend.  The files
>ssl_util_table.[ch] and ssl_scache_shmht.c can be removed after applying
>this patch.

I don't necessarily disagree for 2.1-dev, but we've sort of concurred that
users shouldn't have to switch modules or configuration significantly in
a given minor version (e.g. 2.0).  Now I'm not arguing that's it's very
unlikely a user successfully used shmht.c, but as a matter of principle,
we shouldn't drop this away from 2.0.

Suggestion, apply the fixes to 2.1/2.0 and let's revisit this decision when
the list is ready to consider the 2.2 release.  Perhaps some interested
parties will step up and demonstrate its extra value.  If not, then it will 
be time to drop it from the 2.1 tree before we bless 2.2.

Bill