httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <andreas.wieczo...@gzs.de>
Subject AW: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Date Mon, 29 May 2006 08:11:02 GMT
There have been threads about failover/hotstandby being differently in mod_jk / mod_proxy_balancer
& mod_proxy_ajp:
Status=d was not working in the same way like in mod_jk (worker with status=d are not used
when the other worker of the balancer fails)

Ruediger's last words as far as I know (Feb 28, 2006) concerning this were (see http://www.nabble.com/mod_proxy_balancer+-+failover+%28hot+standby%29-t1200150.html#a3166923)

>I hope (and hoped) to get some feedback by other developers on this issue to clarify the
definition of 'disabled'. 
>Once this is done we can go into the details about how to implement this. 

I assume the status=d behavior still is a difference between mod_jk and mod_proxy_balacer
/ _ajp ...?

Regards,
Andreas

-----Ursprüngliche Nachricht-----
Von: Ruediger Pluem [mailto:rpluem@apache.org] 
Gesendet: 28.05.2006 23:00
An: dev@httpd.apache.org
Betreff: Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?




On 05/28/2006 03:18 PM, Jeff Trawick wrote:
> On 5/27/06, Ruediger Pluem  wrote:
> 
>>
>>
>> On 05/27/2006 03:58 PM, Jeff Trawick wrote:
>>
>> >
>> > Are there still fundamental pieces missing from mod_proxy_ajp +
>> > mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
>> > the natural solution for anybody on Apache >= 2.2?
>>
>> Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do
>> not know if this is regarded as fundamental piece.

Other things I noticed that are different:

1. mod_jk's recycle_timeout and cache_timeout are not exactly matched by mod_proxy's
   smax and ttl. But from my current personal point of view this does not matter.

2. mod_proxy_ajp does miss mod_jk's secret options. Again not critical from my point of view.

3. Currently connections are not checked if they are healthy *before* a request is send
   (something like mod_jk's connect_timeout, prepost_timeout). I think this would be nice
to have,
   but I guess it is not easy to do this in a protocol independent way. So this might be only
   subject to implementation in mod_proxy_ajp.

4. There is no match for mod_jk's recovery_options currently. Furthermore I think some research
   needs to be done about mod_proxy's current behaviour in this situation. I guess this is
important
   to prevent things being twice in your basket :-).


>> > Isn't pass-through of client SSL connection information another
>> > problem with mod_proxy?  (servlets can't access cipher or client
>> > certificate)
>>
>> AFAIK not with mod_proxy_ajp. It seems to pass all these information
>> to Tomcat.
> 
> 
> oops, I meant "... problem with using generic HTTP support with
> mod_proxy -- mod_proxy_http"; I agree, the functional problem doesn't

I do not know if there is any standard in passing such information to the backend
via HTTP, but I think you can pick up all SSL information that is available as env
variables and add them as request headers to the backend request via mod_headers.
Is this a sufficient solution for the problem?

Regarding mod_proxy_http the following TODO's come up to my mind:

1. Currently we cannot handle keepalive connections to SSL backends.
2. There are some problems if the backend closes a keepalive connection by itself
   due to a timeout. See also:

  http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c20060220135107.GA4335@redhat.com%3e
  http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c43F0FBFD.6040403@apache.org%3e

  and PR3770 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37770).


Regards

Rüdiger


Dieses Dokument ist vertraulich und ausschliesslich fuer den Adressaten bestimmt. Falls Sie
diese E-Mail versehentlich bekommen haben, informieren Sie uns bitte unverzueglich und loeschen
Sie diese Nachricht von Ihrem Computer. Jegliche Art von Reproduktion, Verbreitung, Vervielfaeltigung,
Modifikation, Verteilung und/oder Publikation dieser E-Mail Nachricht ist untersagt. 
Die in dieser E-Mail enthaltenen Angaben und Erklaerungen sind unverbindlich. Haftungsansprueche
des Empfaengers jeglicher Art werden ausgeschlossen. Die GZS schliesst ausser fuer den Fall
von Vorsatz oder grober Fahrlaessigkeit die Haftung fuer jeglichen Verlust oder Schaeden durch
virenbefallene Software oder E-Mails aus.
-----------------------------------------------------------------------------------------------------------
This message contains confidential information and is intended only for the named individual.
If you are not the named addressee, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this message in error
and delete this e-message from your system.
No reliance may be placed on this message without written confirmation of its contents from
an authorized representative. GZS accepts no liability for loss or damage caused by software
viruses except in case of gross negligence or willful behaviour.


Mime
View raw message