httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VIS <>
Subject AW: AW: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Date Mon, 20 Feb 2006 16:17:39 GMT

> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski 
> Jim Jagielski wrote:
> > 
> > Hmmm... Possibly SSL requires close_on_recycle. Or, at
> > least, using that flag as required for SSL.
> > 
> I don't have time to explain in more detail, but the more
> I look over the old way, it was to maintain some sort
> of local state-of-health on the socket pre-and-post
> each request... As such, I'm *thinking* that the
> code patch should be reverted to maintain that
> logic, and extend it, rather than remove it...

I think the SSL problem is caused by throwing away the conn_rec
entry for the backend and create a new one for each request.
That does not sound right, but I admit that keeping it must be
carefully examinated due to several possible issues. Two
that I can see immeditately are:

1. memory pools
2. filters

For me that puts the question on the table if using "fake" request_rec
and conn_rec structures for the backend connections is really a good
idea. This "misuse" already leads to problems in other areas.
But reworking this will take much time and work and is only mid to
long term. Might be easier if we have a http / https client library
as part of httpd or apr-util.

The other problem Joe mentioned is a problem that I feared.
See 2. in
I also need to think about Joes ideas in more detail before
responding to them. They might be a good solution to this. 

Regarding revert. The old version is really bad for performance.
So I would like to keep the patch, provided that we can fix the regressions
within a short timeframe (fixes do not need to provide optimal perfomance
, so non persistance for ssl backend connections would be ok for me
as a fix in this context). If not I would propose to revert on trunk
and create a branch to work this out.



View raw message