> -----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 http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL PROTECTED] 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. Regards Rüdiger
