You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev <de...@hanik.com> on 2004/07/21 18:16:11 UTC
Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
ok, there are two very simple memory friendly ways to do sticky load balancing.
And as a matter of fact, this is how some hardware loadbalancers do it.
1. Set a cookie on the clients machine - no server memory to hold a map
2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory
map needed.
The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options
above. So right then and there, there is one less thing to configure.
Filip
----- Original Message -----
From: "Graham Leggett" <mi...@sharp.fm>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, July 21, 2004 9:34 AM
Subject: Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote:
> But I still think we should start with using mod_proxy with http
> protocol, and add the missing load balancing and extra info - if we are
> not happy with the performance and we need a small boost, we could also
> add ajp.
I think this is a good idea.
Solve the general load balancer case first, then you will soon see
whether HTTP works for everybody, or whether there is still a need for
AJP. If there is a need, then someone will develop the AJP part of the
module, but as the AJP module need not cocern itself with load balancing
(that function being handled for it) it will be a far simpler module all
round.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Brian Pane <br...@apache.org>.
Henri Gomez wrote:
> I made some benchs on my Linux Fedora Core 2
> on a P4 2.8ghz / 1Gb RAM :
> Apache 2 alone 1202 req/s
> TC/Coyote 883 req/s
One thing I noticed when looking at Tomcat 5.0.x is that its default,
static-file-delivering servlet does a stat(2) of each path prefix leading
up to the file. A standard installation of Apache 2.x, with FollowSymlinks
enabled, doesn't do these stat calls, for obvious performance reasons.
Is the stat'ing of all the directories leading up to the requested file
in Tomcat intentional (it *is* valuable in some environments for
security purposes), or is it just a side-effect of the implementation?
Brian
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Peter Lin <wo...@gmail.com>.
you can run it in non-Gui mode with -n option.
http://jakarta.apache.org/jmeter/usermanual/get-started.html#non_gui
might help, or not.
peter
On Thu, 22 Jul 2004 15:33:41 +0200, Henri Gomez <hg...@apache.org> wrote:
> Peter Lin wrote:
>
> > the nightly build of jmeter has an alpha sampler that uses Commons
> > HTTPClient. you may want to try that one instead, if you use jmeter
> >
> > peter
>
> made some tests with JMeter 2.0.1 but my laptop is
> way to slow.
>
> I need another smaller stress tool ;(
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Peter Lin wrote:
> the nightly build of jmeter has an alpha sampler that uses Commons
> HTTPClient. you may want to try that one instead, if you use jmeter
>
> peter
made some tests with JMeter 2.0.1 but my laptop is
way to slow.
I need another smaller stress tool ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Peter Lin <wo...@gmail.com>.
the nightly build of jmeter has an alpha sampler that uses Commons
HTTPClient. you may want to try that one instead, if you use jmeter
peter
On Thu, 22 Jul 2004 15:09:19 +0200, Henri Gomez <hg...@apache.org> wrote:
> Remy Maucherat wrote:
>
> > Henri Gomez wrote:
> >
> >> I made some benchs on my Linux Fedora Core 2
> >> on a P4 2.8ghz / 1Gb RAM :
> >>
> >> Apache 2.0.50 in
> >>
> >> - Apache 2.0.50 alone (simple html file)
> >>
> >> - TC 3.3.2/Coyote 1.1
> >>
> >> - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
> >>
> >> JkMount /examples/* local
> >>
> >> worker.local.port=8009
> >> worker.local.host=localhost
> >> worker.local.type=ajp13
> >> worker.local.cachesize=16
> >> worker.local.cache_timeout=600
> >> worker.local.socket_keepalive=1
> >> worker.local.socket_timeout=300
> >>
> >>
> >> - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
> >>
> >> ProxyPass /tc3/ http://localhost:11011/
> >> ProxyPassReverse /tc3/ http://localhost:11011/
> >>
> >>
> >> Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
> >> and both systems are on a switched 100Mbps network :
> >>
> >>
> >> Apache 2 alone 1202 req/s
> >> TC/Coyote 883 req/s
> >> Apache 2 + jk + TC 906 req/s
> >> Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
> >>
> >>
> >> Constatation :
> >>
> >> - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
> >> than the Apache 2 native HTTP.
> >>
> >> - mod_proxy is 50% slower than mod_jk and that's a really bad news.
> >> Also many errors appears, about 4% errors.
> >>
> >> - Tomcat via jk or mod_proxy, when on the same machine make a cpu load
> >> of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
> >>
> >>
> >> How could we optimize mod_proxy settings since I'm using the standard
> >> httpd.conf ?
> >
> >
> > It's quite bad :( Did you check everything was ok using verbose ?
> > ab -n 1 -v 10
> > All your tests show "Keep-Alive requests: 0 " in the result. It
> > should work ok with Tomcat standalone (to be honest, I didn't try 3.3
> > with the current HTTP/1.1 connector), and with Apache as well.
> >
> > ab uses HTTP/1.0 keepalive with the "-k" option.
>
> Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it
> with JMeter :)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> Tim Funk wrote:
>
>> Try siege: http://joedog.org/siege/
>>
>> Despite what the docs say, it runs pretty sweet on cygwin too. (with
>> 2.60b5)
>
>
> Well I've got problem with release 2.59 and 2.60b5, siege seems to
> sleep ? (using HTTP 1.1)
>
> siege -u http://machone/HelloWorldExample.html -b -r10 -c16 ;(
The problems disappears when i change
connection = keep-alive
to
connection = close
Bad, I wanted to test HTTP 1.1 with keep-alive ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Tim Funk wrote:
> Try siege: http://joedog.org/siege/
>
> Despite what the docs say, it runs pretty sweet on cygwin too. (with
> 2.60b5)
Well I've got problem with release 2.59 and 2.60b5, siege seems to
sleep ? (using HTTP 1.1)
siege -u http://machone/HelloWorldExample.html -b -r10 -c16 ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Tim Funk <fu...@joedog.org>.
Try siege: http://joedog.org/siege/
Despite what the docs say, it runs pretty sweet on cygwin too. (with 2.60b5)
-Tim
Henri Gomez wrote:
> jean-frederic clere wrote:
>
>>>
>>>
>>
>> mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is <1.1
>> is that correct?
>>
>> The request was (from ab):
>> +++
>> GET /examples/ HTTP/1.0^M
>> User-Agent: ApacheBench/2.0.40-dev^M
>> Connection: Keep-Alive^M
>> Host: localhost:7779^M
>> Accept: */*^M
>> ^M
>> +++
>
>
> I'm still looking for a bench tester supporting HTTP 1.1, jmeter is too
> hog for my PIII 1Ghz ;(
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
>>
>>
>
> mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is <1.1
> is that correct?
>
> The request was (from ab):
> +++
> GET /examples/ HTTP/1.0^M
> User-Agent: ApacheBench/2.0.40-dev^M
> Connection: Keep-Alive^M
> Host: localhost:7779^M
> Accept: */*^M
> ^M
> +++
I'm still looking for a bench tester supporting HTTP 1.1, jmeter is too
hog for my PIII 1Ghz ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by jean-frederic clere <jf...@Fujitsu-Siemens.com>.
Henri Gomez wrote:
> Remy Maucherat wrote:
>
>> Henri Gomez wrote:
>>
>>> I made some benchs on my Linux Fedora Core 2
>>> on a P4 2.8ghz / 1Gb RAM :
>>>
>>> Apache 2.0.50 in
>>>
>>> - Apache 2.0.50 alone (simple html file)
>>>
>>> - TC 3.3.2/Coyote 1.1
>>>
>>> - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
>>>
>>> JkMount /examples/* local
>>>
>>> worker.local.port=8009
>>> worker.local.host=localhost
>>> worker.local.type=ajp13
>>> worker.local.cachesize=16
>>> worker.local.cache_timeout=600
>>> worker.local.socket_keepalive=1
>>> worker.local.socket_timeout=300
>>>
>>>
>>> - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
>>>
>>> ProxyPass /tc3/ http://localhost:11011/
>>> ProxyPassReverse /tc3/ http://localhost:11011/
>>>
>>>
>>> Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
>>> and both systems are on a switched 100Mbps network :
>>>
>>>
>>> Apache 2 alone 1202 req/s
>>> TC/Coyote 883 req/s
>>> Apache 2 + jk + TC 906 req/s
>>> Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
>>>
>>>
>>> Constatation :
>>>
>>> - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
>>> than the Apache 2 native HTTP.
>>>
>>> - mod_proxy is 50% slower than mod_jk and that's a really bad news.
>>> Also many errors appears, about 4% errors.
>>>
>>> - Tomcat via jk or mod_proxy, when on the same machine make a cpu load
>>> of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
>>>
>>>
>>> How could we optimize mod_proxy settings since I'm using the standard
>>> httpd.conf ?
>>
>>
>>
>> It's quite bad :( Did you check everything was ok using verbose ?
>> ab -n 1 -v 10
>> All your tests show "Keep-Alive requests: 0 " in the result. It
>> should work ok with Tomcat standalone (to be honest, I didn't try 3.3
>> with the current HTTP/1.1 connector), and with Apache as well.
>>
>> ab uses HTTP/1.0 keepalive with the "-k" option.
>
>
> Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it
> with JMeter :)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
mod_proxy in ap_proxy_http_cleanup() closes the socket if HTTP is <1.1 is that
correct?
The request was (from ab):
+++
GET /examples/ HTTP/1.0^M
User-Agent: ApacheBench/2.0.40-dev^M
Connection: Keep-Alive^M
Host: localhost:7779^M
Accept: */*^M
^M
+++
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Henri Gomez wrote:
>
>> I made some benchs on my Linux Fedora Core 2
>> on a P4 2.8ghz / 1Gb RAM :
>>
>> Apache 2.0.50 in
>>
>> - Apache 2.0.50 alone (simple html file)
>>
>> - TC 3.3.2/Coyote 1.1
>>
>> - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
>>
>> JkMount /examples/* local
>>
>> worker.local.port=8009
>> worker.local.host=localhost
>> worker.local.type=ajp13
>> worker.local.cachesize=16
>> worker.local.cache_timeout=600
>> worker.local.socket_keepalive=1
>> worker.local.socket_timeout=300
>>
>>
>> - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
>>
>> ProxyPass /tc3/ http://localhost:11011/
>> ProxyPassReverse /tc3/ http://localhost:11011/
>>
>>
>> Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
>> and both systems are on a switched 100Mbps network :
>>
>>
>> Apache 2 alone 1202 req/s
>> TC/Coyote 883 req/s
>> Apache 2 + jk + TC 906 req/s
>> Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
>>
>>
>> Constatation :
>>
>> - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
>> than the Apache 2 native HTTP.
>>
>> - mod_proxy is 50% slower than mod_jk and that's a really bad news.
>> Also many errors appears, about 4% errors.
>>
>> - Tomcat via jk or mod_proxy, when on the same machine make a cpu load
>> of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
>>
>>
>> How could we optimize mod_proxy settings since I'm using the standard
>> httpd.conf ?
>
>
> It's quite bad :( Did you check everything was ok using verbose ?
> ab -n 1 -v 10
> All your tests show "Keep-Alive requests: 0 " in the result. It
> should work ok with Tomcat standalone (to be honest, I didn't try 3.3
> with the current HTTP/1.1 connector), and with Apache as well.
>
> ab uses HTTP/1.0 keepalive with the "-k" option.
Well I was thinking ab (2.0.40) use HTTP 1.1. I'll retest it
with JMeter :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> I made some benchs on my Linux Fedora Core 2
> on a P4 2.8ghz / 1Gb RAM :
>
> Apache 2.0.50 in
>
> - Apache 2.0.50 alone (simple html file)
>
> - TC 3.3.2/Coyote 1.1
>
> - Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
>
> JkMount /examples/* local
>
> worker.local.port=8009
> worker.local.host=localhost
> worker.local.type=ajp13
> worker.local.cachesize=16
> worker.local.cache_timeout=600
> worker.local.socket_keepalive=1
> worker.local.socket_timeout=300
>
>
> - Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
>
> ProxyPass /tc3/ http://localhost:11011/
> ProxyPassReverse /tc3/ http://localhost:11011/
>
>
> Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
> and both systems are on a switched 100Mbps network :
>
>
> Apache 2 alone 1202 req/s
> TC/Coyote 883 req/s
> Apache 2 + jk + TC 906 req/s
> Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
>
>
> Constatation :
>
> - Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
> than the Apache 2 native HTTP.
>
> - mod_proxy is 50% slower than mod_jk and that's a really bad news.
> Also many errors appears, about 4% errors.
>
> - Tomcat via jk or mod_proxy, when on the same machine make a cpu load
> of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
>
>
> How could we optimize mod_proxy settings since I'm using the standard
> httpd.conf ?
It's quite bad :( Did you check everything was ok using verbose ?
ab -n 1 -v 10
All your tests show "Keep-Alive requests: 0 " in the result. It
should work ok with Tomcat standalone (to be honest, I didn't try 3.3
with the current HTTP/1.1 connector), and with Apache as well.
ab uses HTTP/1.0 keepalive with the "-k" option.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
I made some benchs on my Linux Fedora Core 2
on a P4 2.8ghz / 1Gb RAM :
Apache 2.0.50 in
- Apache 2.0.50 alone (simple html file)
- TC 3.3.2/Coyote 1.1
- Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
JkMount /examples/* local
worker.local.port=8009
worker.local.host=localhost
worker.local.type=ajp13
worker.local.cachesize=16
worker.local.cache_timeout=600
worker.local.socket_keepalive=1
worker.local.socket_timeout=300
- Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
ProxyPass /tc3/ http://localhost:11011/
ProxyPassReverse /tc3/ http://localhost:11011/
Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
and both systems are on a switched 100Mbps network :
Apache 2 alone 1202 req/s
TC/Coyote 883 req/s
Apache 2 + jk + TC 906 req/s
Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
Constatation :
- Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
than the Apache 2 native HTTP.
- mod_proxy is 50% slower than mod_jk and that's a really bad news.
Also many errors appears, about 4% errors.
- Tomcat via jk or mod_proxy, when on the same machine make a cpu load
of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
How could we optimize mod_proxy settings since I'm using the standard
httpd.conf ?
------
Complete bench results :
Apache 2.0.50 alone (simple html file)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/HelloWorldExample.html
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache/2.0.50
Server Hostname: machone
Server Port: 80
Document Path: /HelloWorldExample.html
Document Length: 459 bytes
Concurrency Level: 16
Time taken for tests: 166.299127 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 145800000 bytes
HTML transferred: 91800000 bytes
Requests per second: 1202.65 [#/sec] (mean)
Time per request: 13.304 [ms] (mean)
Time per request: 0.831 [ms] (mean, across all concurrent requests)
Transfer rate: 856.18 [Kbytes/sec] received
Tomcat 3.3.2 using the Coyote 1.1 HTTP connector
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone:11011/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: machone
Server Port: 11011
Document Path: /examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 226.485671 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 105400000 bytes
HTML transferred: 80000000 bytes
Requests per second: 883.06 [#/sec] (mean)
Time per request: 18.119 [ms] (mean)
Time per request: 1.132 [ms] (mean, across all concurrent requests)
Transfer rate: 454.46 [Kbytes/sec] received
Apache 2.0.50 + jk 1.2.6 + Tomcat 3.3.2 (via Coyote JK2 connector)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache/2.0.50
Server Hostname: machone
Server Port: 80
Document Path: /examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 220.637261 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 110400000 bytes
HTML transferred: 80000000 bytes
Requests per second: 906.47 [#/sec] (mean)
Time per request: 17.651 [ms] (mean)
Time per request: 1.103 [ms] (mean, across all concurrent requests)
Transfer rate: 488.64 [Kbytes/sec] received
Apache 2.0.50 + mod_proxy + Tomcat 3.3.2 (via Coyote HTTP connector)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/tc3/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: machone
Server Port: 80
Document Path: /tc3/examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 401.717641 seconds
Complete requests: 200000
Failed requests: 8046
(Connect: 0, Length: 8046, Exceptions: 0)
Write errors: 0
Non-2xx responses: 8046
Keep-Alive requests: 0
Total transferred: 108724136 bytes
HTML transferred: 79299998 bytes
Requests per second: 497.86 [#/sec] (mean)
Time per request: 32.137 [ms] (mean)
Time per request: 2.009 [ms] (mean, across all concurrent requests)
Transfer rate: 264.30 [Kbytes/sec] received
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> I made some benchs yesterday on my laptop between :
>
> - TC 3.3.2/Coyote
> - Apache 2.0.49 alone (simple html file)
> - Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2
> - Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2
> - Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1).
>
> I'll redo them today on a faster machines since the results where
> a little too random but the benchs raise some questions :
>
> - I'm using ab (ApacheBench) and wonder if the -k (keep alive)
> if HTTP keep-alive is really used ?
I do my testing with -k usually, and with something like -c 20, to get
an average load level (I'm using that on Cygwin, so high concurrency
does't quite work in localhost). It seems like keepalive is being used
often, and this factors out some of the network stack overhead when I'm
profiling stuff.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Henri Gomez wrote:
> - I'm using ab (ApacheBench) and wonder if the -k (keep alive)
> if HTTP keep-alive is really used ?
>
> - Did mod_proxy keep a connection cache ?
Proxy's HTTP module will reuse the same connection from previous
connections if keepalives are being used, it doesn't keep a connection
cache for more than one connection at a time.
This behaviour is limited to proxy_http though. There is nothing inside
proxy that would prevent proxy_ajp from keeping a connection cache.
Regards,
Graham
--
Re: mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by jean-frederic clere <jf...@Fujitsu-Siemens.com>.
Henri Gomez wrote:
> Remy Maucherat wrote:
>
>> Filip Hanik - Dev wrote:
>>
>>> ok, there are two very simple memory friendly ways to do sticky load
>>> balancing.
>>> And as a matter of fact, this is how some hardware loadbalancers do it.
>>>
>>> 1. Set a cookie on the clients machine - no server memory to hold a map
>>> 2. If the client doesn't accept cookies, do a simple sticky load
>>> balancing based on the IP of the client request. Again, no memory
>>> map needed.
>>>
>>> The current jvmRoute addition to JSESSIONID is not really needed,
>>> since it doesn't add that much of a benefit over the two options
>>> above. So right then and there, there is one less thing to configure.
>>>
>>>
>> It's cool to have one less thing to configure, but it seems to me
>> jvmRoute is the most reliable and efficient way of doing stickiness
>> (the cookie way is intrusive, and the IP way is highly inaccurate).
>
>
> Well it seems the discussion advance quickly and on the right direction,
> a true ASF members colaboration.
>
> I made some benchs yesterday on my laptop between :
>
> - TC 3.3.2/Coyote
> - Apache 2.0.49 alone (simple html file)
> - Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2
> - Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2
> - Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1).
>
> I'll redo them today on a faster machines since the results where
> a little too random but the benchs raise some questions :
>
> - I'm using ab (ApacheBench) and wonder if the -k (keep alive)
> if HTTP keep-alive is really used ?
Why?
Remember to run ab on a separate (fast) machine otherwise the results are random ;-)
>
> - Did mod_proxy keep a connection cache ?
>
It does not close the socket to the proxy when using HTTP/1.1 and "Connection:"
is not "close".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
I made some benchs on my Linux Fedora Core 2
on a P4 2.8ghz / 1Gb RAM :
Apache 2.0.50 in
- Apache 2.0.50 alone (simple html file)
- TC 3.3.2/Coyote 1.1
- Apache 2.0.50 + jk 1.2.6 + TC 3.3.2/jk2
JkMount /examples/* local
worker.local.port=8009
worker.local.host=localhost
worker.local.type=ajp13
worker.local.cachesize=16
worker.local.cache_timeout=600
worker.local.socket_keepalive=1
worker.local.socket_timeout=300
- Apache 2.0.50 + mod_proxy + TC 3.3.2 (Coyote 1.1).
ProxyPass /tc3/ http://localhost:11011/
ProxyPassReverse /tc3/ http://localhost:11011/
Apache Bench is running on another machine, Windows 2000 P3 1Ghz,
and both systems are on a switched 100Mbps network :
Apache 2 alone 1202 req/s
TC/Coyote 883 req/s
Apache 2 + jk + TC 906 req/s
Apache 2 + proxy + TC 497.req/s (but with 8000 errors ;(
Constatation :
- Remy make a tremendous works since Coyote HTTP 1.1 is only 15% slower
than the Apache 2 native HTTP.
- mod_proxy is 50% slower than mod_jk and that's a really bad news.
Also many errors appears, about 4% errors.
- Tomcat via jk or mod_proxy, when on the same machine make a cpu load
of 60% system and 30% user. Tomcat alone is 33% system and 10% user.
How could we optimize mod_proxy settings since I'm using the standard
httpd.conf ?
------
Complete bench results :
Apache 2.0.50 alone (simple html file)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/HelloWorldExample.html
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache/2.0.50
Server Hostname: machone
Server Port: 80
Document Path: /HelloWorldExample.html
Document Length: 459 bytes
Concurrency Level: 16
Time taken for tests: 166.299127 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 145800000 bytes
HTML transferred: 91800000 bytes
Requests per second: 1202.65 [#/sec] (mean)
Time per request: 13.304 [ms] (mean)
Time per request: 0.831 [ms] (mean, across all concurrent requests)
Transfer rate: 856.18 [Kbytes/sec] received
Tomcat 3.3.2 using the Coyote 1.1 HTTP connector
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone:11011/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: machone
Server Port: 11011
Document Path: /examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 226.485671 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 105400000 bytes
HTML transferred: 80000000 bytes
Requests per second: 883.06 [#/sec] (mean)
Time per request: 18.119 [ms] (mean)
Time per request: 1.132 [ms] (mean, across all concurrent requests)
Transfer rate: 454.46 [Kbytes/sec] received
Apache 2.0.50 + jk 1.2.6 + Tomcat 3.3.2 (via Coyote JK2 connector)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache/2.0.50
Server Hostname: machone
Server Port: 80
Document Path: /examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 220.637261 seconds
Complete requests: 200000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 110400000 bytes
HTML transferred: 80000000 bytes
Requests per second: 906.47 [#/sec] (mean)
Time per request: 17.651 [ms] (mean)
Time per request: 1.103 [ms] (mean, across all concurrent requests)
Transfer rate: 488.64 [Kbytes/sec] received
Apache 2.0.50 + mod_proxy + Tomcat 3.3.2 (via Coyote HTTP connector)
C:\Program Files\Apache Group\Apache2\bin>ab -k -n 200000 -c 16
http://machone/tc3/examples/servlet/HelloWorldExample
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.8 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking machone (be patient)
Completed 20000 requests
Completed 40000 requests
Completed 60000 requests
Completed 80000 requests
Completed 100000 requests
Completed 120000 requests
Completed 140000 requests
Completed 160000 requests
Completed 180000 requests
Finished 200000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: machone
Server Port: 80
Document Path: /tc3/examples/servlet/HelloWorldExample
Document Length: 400 bytes
Concurrency Level: 16
Time taken for tests: 401.717641 seconds
Complete requests: 200000
Failed requests: 8046
(Connect: 0, Length: 8046, Exceptions: 0)
Write errors: 0
Non-2xx responses: 8046
Keep-Alive requests: 0
Total transferred: 108724136 bytes
HTML transferred: 79299998 bytes
Requests per second: 497.86 [#/sec] (mean)
Time per request: 32.137 [ms] (mean)
Time per request: 2.009 [ms] (mean, across all concurrent requests)
Transfer rate: 264.30 [Kbytes/sec] received
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
mod_proxy details : WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Filip Hanik - Dev wrote:
>
>> ok, there are two very simple memory friendly ways to do sticky load
>> balancing.
>> And as a matter of fact, this is how some hardware loadbalancers do it.
>>
>> 1. Set a cookie on the clients machine - no server memory to hold a map
>> 2. If the client doesn't accept cookies, do a simple sticky load
>> balancing based on the IP of the client request. Again, no memory
>> map needed.
>>
>> The current jvmRoute addition to JSESSIONID is not really needed,
>> since it doesn't add that much of a benefit over the two options
>> above. So right then and there, there is one less thing to configure.
>>
>>
> It's cool to have one less thing to configure, but it seems to me
> jvmRoute is the most reliable and efficient way of doing stickiness (the
> cookie way is intrusive, and the IP way is highly inaccurate).
Well it seems the discussion advance quickly and on the right direction,
a true ASF members colaboration.
I made some benchs yesterday on my laptop between :
- TC 3.3.2/Coyote
- Apache 2.0.49 alone (simple html file)
- Apache 2.0.49 + jk 1.2.6 + TC 3.3.2/jk2
- Apache 2.0.49 + jk 1.2.6 + 2 * TC 3.3.2/jk2
- Apache 2.0.49 + mod_proxy + TC 3.3.2 (Coyote 1.1).
I'll redo them today on a faster machines since the results where
a little too random but the benchs raise some questions :
- I'm using ab (ApacheBench) and wonder if the -k (keep alive)
if HTTP keep-alive is really used ?
- Did mod_proxy keep a connection cache ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Graham Leggett wrote:
>
>> Remy Maucherat wrote:
>>
>>> It's cool to have one less thing to configure, but it seems to me
>>> jvmRoute is the most reliable and efficient way of doing stickiness
>>
>>
>>
>> Can you describe the jvmRoute method to me?
>>
> It's really dumb: we append the node name to the session id when it's
> generated (it ends up as the JSESSIONID cookie value). Of course, the
> downside is that you have to configure stuff on each node :/
Or we could have a "reasonable default" - like the ajp ip/port of the
host ( or md5 of it ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Graham Leggett wrote:
> Remy Maucherat wrote:
>
>> It's cool to have one less thing to configure, but it seems to me
>> jvmRoute is the most reliable and efficient way of doing stickiness
>
>
> Can you describe the jvmRoute method to me?
>
It's really dumb: we append the node name to the session id when it's
generated (it ends up as the JSESSIONID cookie value). Of course, the
downside is that you have to configure stuff on each node :/
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Remy Maucherat wrote:
> It's cool to have one less thing to configure, but it seems to me
> jvmRoute is the most reliable and efficient way of doing stickiness
Can you describe the jvmRoute method to me?
> (the
> cookie way is intrusive, and the IP way is highly inaccurate).
I agree on the IP way being inaccurate (and have argued long and hard
against people who couldn't understand that the same browser could
easily come in from one of many IP addresses, changing all the time as
they go).
Currently tomcat handles sessions as either a) a cookie or b) a
parameter. We could easily teach proxy_sticky that stickiness is based
on either of these two.
Regards,
Graham
--
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev wrote:
>ok, there are two very simple memory friendly ways to do sticky load balancing.
>And as a matter of fact, this is how some hardware loadbalancers do it.
>
>1. Set a cookie on the clients machine - no server memory to hold a map
>2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory
>map needed.
>
>The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options
>above. So right then and there, there is one less thing to configure.
>
>
It's cool to have one less thing to configure, but it seems to me
jvmRoute is the most reliable and efficient way of doing stickiness (the
cookie way is intrusive, and the IP way is highly inaccurate).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: AJP protocol description??
Posted by Henri Gomez <hg...@apache.org>.
Bill Barker wrote:
> ----- Original Message -----
> From: "Ian Holsman" <li...@holsman.net>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Wednesday, July 21, 2004 8:42 PM
> Subject: AJP protocol description??
>
>
>
>>Hi..
>>
>>I'm lurker from over in httpd-dev
>>
>>do you guys have a description of the AJP protocol?
>>
>
>
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html
Ian don't forget to take a look at AJP extensions proposal :
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13-extensions-proposal.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: AJP protocol description??
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Ian Holsman" <li...@holsman.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, July 21, 2004 8:42 PM
Subject: AJP protocol description??
> Hi..
>
> I'm lurker from over in httpd-dev
>
> do you guys have a description of the AJP protocol?
>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
AJP protocol description??
Posted by Ian Holsman <li...@holsman.net>.
Hi..
I'm lurker from over in httpd-dev
do you guys have a description of the AJP protocol?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
In previous mail I forgot one crucial result:
Ab -n 1000 directly to TC
Time taken for tests: 1.882708 seconds
Ab -n 10000 directly to TC
Time taken for tests: 17.244797 seconds
I'll leave the calculation to others.
MT.
Re: jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Günter Knauf wrote:
>
>> Hi,
>>
>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>
>>
>> JFC's portable.h breaks NetWare too; should I now extend the #ifndef
>> like Henry did?
>
>
> I don't see what is wrong:
> jk/native/common/portable.h should be created from portable.h.in when
> doing configure.
Well iSeries and Windows didn't use autoconf
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk 1.2.6 to be tagged
Posted by Mladen Turk <mt...@apache.org>.
jean-frederic clere wrote:
> >
> > JFC's portable.h breaks NetWare too; should I now extend
> the #ifndef like Henry did?
>
That's the quickest way. The proper would be to have protable.hw and
portable.nw (like APR, Apache, etc... have).
> I don't see what is wrong:
> jk/native/common/portable.h should be created from
> portable.h.in when doing configure.
>
We don't use configure.
MT.
Re: jk 1.2.6 to be tagged
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Günter Knauf wrote:
> Hi,
>
>>http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>
> JFC's portable.h breaks NetWare too; should I now extend the #ifndef like Henry did?
I don't see what is wrong:
jk/native/common/portable.h should be created from portable.h.in when doing
configure.
> I guess there are probably more platforms which dont have portable.h, so it's perhaps a better approach to do:
> #ifdef HAVE_PORTABLE_H
> #include <portable.h>
> #endif
>
> otherwise it would look like this:
> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
> #include "portable.h"
> #else
> #if defined(NETWARE) && !defined(__NOVELL_LIBC__)
> #include <whatever is necessary for getting the vsnprintf, snprint replacements>
> #else
> #define HAVE_VSNPRINTF
> #define HAVE_SNPRINTF
> #endif
>
> personally I think its not needed anyway: if we have a good implementation for vsnprintf and friends, then why we do not trust it and use it in general over all platforms??
> What's the benefit of using the OS APIs if present?
>
> Guenter.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> Günter Knauf wrote:
>>
>>> Hi,
>>>
>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>
>>>
>>>
>>> JFC's portable.h breaks NetWare too; should I now extend the #ifndef
>>> like Henry did? I guess there are probably more platforms which dont
>>> have portable.h, so it's perhaps a better approach to do:
>>> #ifdef HAVE_PORTABLE_H
>>> #include <portable.h>
>>> #endif
>>>
>>> otherwise it would look like this:
>>> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
>>> #include "portable.h"
>>> #else
>>> #if defined(NETWARE) && !defined(__NOVELL_LIBC__)
>>> #include <whatever is necessary for getting the vsnprintf, snprint
>>> replacements>
>>> #else
>>> #define HAVE_VSNPRINTF
>>> #define HAVE_SNPRINTF
>>> #endif
>>>
>>> personally I think its not needed anyway: if we have a good
>>> implementation for vsnprintf and friends, then why we do not trust it
>>> and use it in general over all platforms??
>>> What's the benefit of using the OS APIs if present?
>>
>>
>>
>> There is also reports for Solaris 8.0 where portable.h is not present ;(
>
>
> May be we should have a default ./common/portable.h
> containing:
>
> /* On most platform this file is overwritten when doing configure */
> #define PACKAGE "mod_jk"
> #define VERSION "1.2.6"
>
> BTW: The version is wrong in configure.in should be VERSION=1.2.6
ok, I'll reworked on CVS to fix all of these and making now new tarballs.
The jk 1.2.6 release (with fixes) was tagged as JK_1_2_6_rel
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by jean-frederic clere <jf...@Fujitsu-Siemens.com>.
Henri Gomez wrote:
> Günter Knauf wrote:
>
>> Hi,
>>
>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>
>>
>> JFC's portable.h breaks NetWare too; should I now extend the #ifndef
>> like Henry did? I guess there are probably more platforms which dont
>> have portable.h, so it's perhaps a better approach to do:
>> #ifdef HAVE_PORTABLE_H
>> #include <portable.h>
>> #endif
>>
>> otherwise it would look like this:
>> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
>> #include "portable.h"
>> #else
>> #if defined(NETWARE) && !defined(__NOVELL_LIBC__)
>> #include <whatever is necessary for getting the vsnprintf, snprint
>> replacements>
>> #else
>> #define HAVE_VSNPRINTF
>> #define HAVE_SNPRINTF
>> #endif
>>
>> personally I think its not needed anyway: if we have a good
>> implementation for vsnprintf and friends, then why we do not trust it
>> and use it in general over all platforms??
>> What's the benefit of using the OS APIs if present?
>
>
> There is also reports for Solaris 8.0 where portable.h is not present ;(
May be we should have a default ./common/portable.h
containing:
/* On most platform this file is overwritten when doing configure */
#define PACKAGE "mod_jk"
#define VERSION "1.2.6"
BTW: The version is wrong in configure.in should be VERSION=1.2.6
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
Günter Knauf wrote:
> Hi,
>
>>http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>
> JFC's portable.h breaks NetWare too; should I now extend the #ifndef like Henry did? I guess there are probably more platforms which dont have portable.h, so it's perhaps a better approach to do:
> #ifdef HAVE_PORTABLE_H
> #include <portable.h>
> #endif
>
> otherwise it would look like this:
> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
> #include "portable.h"
> #else
> #if defined(NETWARE) && !defined(__NOVELL_LIBC__)
> #include <whatever is necessary for getting the vsnprintf, snprint replacements>
> #else
> #define HAVE_VSNPRINTF
> #define HAVE_SNPRINTF
> #endif
>
> personally I think its not needed anyway: if we have a good implementation for vsnprintf and friends, then why we do not trust it and use it in general over all platforms??
> What's the benefit of using the OS APIs if present?
There is also reports for Solaris 8.0 where portable.h is not present ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
JFC's portable.h breaks NetWare too; should I now extend the #ifndef like Henry did? I guess there are probably more platforms which dont have portable.h, so it's perhaps a better approach to do:
#ifdef HAVE_PORTABLE_H
#include <portable.h>
#endif
otherwise it would look like this:
#if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
#include "portable.h"
#else
#if defined(NETWARE) && !defined(__NOVELL_LIBC__)
#include <whatever is necessary for getting the vsnprintf, snprint replacements>
#else
#define HAVE_VSNPRINTF
#define HAVE_SNPRINTF
#endif
personally I think its not needed anyway: if we have a good implementation for vsnprintf and friends, then why we do not trust it and use it in general over all platforms??
What's the benefit of using the OS APIs if present?
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
NetWare binaries for Apache 1.3.x, 2.0.x, 2.1-dev, Netscape are available for testing:
http://www.gknw.com/test/jtc/
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Günter Knauf wrote:
> Hi,
>
>>I don't get the problems on my 7.2 and 9.0 ;-(
>
> hmm, maybe it's a 7.1, or 7.0 box; I will check;
> but I looked already with man inet_addr and found ulong as return value, and not in_add_t;
> do we have any chance that configure detects if we have in_addr_t or not?
Yes, I will look how it is done in APR.
>
> Guenter.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> I don't get the problems on my 7.2 and 9.0 ;-(
hmm, maybe it's a 7.1, or 7.0 box; I will check;
but I looked already with man inet_addr and found ulong as return value, and not in_add_t;
do we have any chance that configure detects if we have in_addr_t or not?
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: new tarballs for jk 1.2.6
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
> Thanks to see if it fix Netware and Windows problems.
all NetWare targets build fine.
> Reports for Suse problems and in_addr didn't appears for JFC and I,
> so I mark them as WORKFORME
I would bet we will get a lot of BZ soon......, but let's see, maybe I'm wrong...
Guenter.
BTW: does anyone else still get the nasty autoresponders?
Since my last post about it now its reduced from 12 to 3, but those 3 are coming all the time when I post something...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Günter Knauf wrote:
> Hi,
>
>>http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>
> I've just tried to build on Linux, and it breaks in jki_connect.c on two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on the second because its defined as struct and not ulong;
> furthermore I had exactly the same issue with another project, and we killed in_addr_t usage.
> If you do a Google for in_addr_t you can directly see that this is a problem on many platforms, seems to me that some have it defined as unsigned long, others as struct, and the rest doesnt have it defined at all...
> I will this weekend examine this further, unless someone beats me...
I don't get the problems on my 7.2 and 9.0 ;-(
>
> but I think this is a big showstopper, and we should probably hold the release until this is fixed...
>
> Guenter.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: new tarballs for jk 1.2.6
Posted by Mladen Turk <mt...@apache.org>.
It builds on WIN32.
Since I already uploaded the binaries, they'll just stay in place, since
nothing actually changed.
MT.
> -----Original Message-----
> From: Henri Gomez [mailto:hgomez@apache.org]
> Sent: Friday, July 23, 2004 12:02 PM
> To: Tomcat Developers List
> Subject: new tarballs for jk 1.2.6
>
> Same location :
>
> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>
> Regards.
>
> Thanks to see if it fix Netware and Windows problems.
>
> Reports for Suse problems and in_addr didn't appears for JFC
> and I, so I mark them as WORKFORME
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
new tarballs for jk 1.2.6
Posted by Henri Gomez <hg...@apache.org>.
Same location :
http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
Regards.
Thanks to see if it fix Netware and Windows problems.
Reports for Suse problems and in_addr didn't appears for JFC and I,
so I mark them as WORKFORME
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Henri Gomez <hg...@apache.org>.
Günter Knauf wrote:
> Hi,
>
>>Adding portable.hnw for netware and portable.hw for windoze and #ifdef for
>>AS400
>>is the clean way.
>
>
>>The quick way is adding:
>>+++
>>#if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
>>#include "portable.h"
>>#endif
>>+++
>
> unfortunately it isnt that simple cause I have _two_ different NetWare architectures, a modern one with vsnprintf & friends, and the older one without where I need the replacements:
> for NetWare netscape, jni, apache-1.3 need replacement; only apache-2.0 has vsnprintf coming from the OS...
>
> I had already fixed that in jk_global.h, but if we stay with portable.h I would like to create protable entirely from the Makefile rather than having a protable.hnw for the above reasons - otherwise I would need _two_ : a protable.hnw1 and portable.hnw2; so better I generate it....
>
> I'm very short in time today, but see what I can add to the Makefile....
Well it will be in jk 1.2.7, if we ever release it since I'm a little
borred to see that we still battling against problems fixed by the
use of APR.
I don't know yet what will do with mod_proxy/ajp_proxy, since it appears
that relay via mod_proxy is today 50% slower than with JK and we have to
wait Apache 2.1 to see it, but I feel we should seriously study
our initial idea of mod_ajp using APR and Apache 2.x as main target.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> Adding portable.hnw for netware and portable.hw for windoze and #ifdef for
> AS400
> is the clean way.
> The quick way is adding:
> +++
> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
> #include "portable.h"
> #endif
> +++
unfortunately it isnt that simple cause I have _two_ different NetWare architectures, a modern one with vsnprintf & friends, and the older one without where I need the replacements:
for NetWare netscape, jni, apache-1.3 need replacement; only apache-2.0 has vsnprintf coming from the OS...
I had already fixed that in jk_global.h, but if we stay with portable.h I would like to create protable entirely from the Makefile rather than having a protable.hnw for the above reasons - otherwise I would need _two_ : a protable.hnw1 and portable.hnw2; so better I generate it....
I'm very short in time today, but see what I can add to the Makefile....
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> jean-frederic clere wrote:
>>
>>> Henri Gomez wrote:
>>>
>>>> jean-frederic clere wrote:
>>>>
>>>>> Henri Gomez wrote:
>>>>>
>>>>>> Günter Knauf wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've just tried to build on Linux, and it breaks in jki_connect.c
>>>>>>> on two boxes, SuSE 7.2 and SuSE9, on the first because no
>>>>>>> in_addr_t, on the second because its defined as struct and not
>>>>>>> ulong;
>>>>>>> furthermore I had exactly the same issue with another project,
>>>>>>> and we killed in_addr_t usage.
>>>>>>> If you do a Google for in_addr_t you can directly see that this
>>>>>>> is a problem on many platforms, seems to me that some have it
>>>>>>> defined as unsigned long, others as struct, and the rest doesnt
>>>>>>> have it defined at all...
>>>>>>> I will this weekend examine this further, unless someone beats me...
>>>>>>>
>>>>>>> but I think this is a big showstopper, and we should probably
>>>>>>> hold the release until this is fixed...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well I didn't have this problem on the 3 differents Liux distros :
>>>>>>
>>>>>> - Fedora Core 2
>>>>>>
>>>>>> - Suse 9.0 (i386)
>>>>>>
>>>>>> - Suse 8.0 (PPC)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I see another problem autom4te.cache should be removed before doing
>>>>> the tarball.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I run the buildconf.sh. May be that's the problem ?
>>>
>>>
>>>
>>>
>>> The problem is in buildconf.sh: I have fixed it.
>>>
>>> If you leave autom4te.cache in the distribution and someone makes
>>> automake using a different automake than the one you have used when
>>> preparing the tarball *very* strange things will happend...
>>
>>
>>
>>
>> And for the portable.h was could we do ?
>
>
> Adding portable.hnw for netware and portable.hw for windoze and #ifdef
> for AS400 is the clean way.
>
> The quick way is adding:
> +++
> #if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
> #include "portable.h"
> #endif
> +++
You understand why I wish a new JK using ONLY APR.
We spend too many times in such dreaded issues ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by jean-frederic clere <jf...@Fujitsu-Siemens.com>.
Henri Gomez wrote:
> jean-frederic clere wrote:
>
>> Henri Gomez wrote:
>>
>>> jean-frederic clere wrote:
>>>
>>>> Henri Gomez wrote:
>>>>
>>>>> Günter Knauf wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've just tried to build on Linux, and it breaks in jki_connect.c
>>>>>> on two boxes, SuSE 7.2 and SuSE9, on the first because no
>>>>>> in_addr_t, on the second because its defined as struct and not ulong;
>>>>>> furthermore I had exactly the same issue with another project, and
>>>>>> we killed in_addr_t usage.
>>>>>> If you do a Google for in_addr_t you can directly see that this is
>>>>>> a problem on many platforms, seems to me that some have it defined
>>>>>> as unsigned long, others as struct, and the rest doesnt have it
>>>>>> defined at all...
>>>>>> I will this weekend examine this further, unless someone beats me...
>>>>>>
>>>>>> but I think this is a big showstopper, and we should probably hold
>>>>>> the release until this is fixed...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well I didn't have this problem on the 3 differents Liux distros :
>>>>>
>>>>> - Fedora Core 2
>>>>>
>>>>> - Suse 9.0 (i386)
>>>>>
>>>>> - Suse 8.0 (PPC)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I see another problem autom4te.cache should be removed before doing
>>>> the tarball.
>>>
>>>
>>>
>>>
>>> I run the buildconf.sh. May be that's the problem ?
>>
>>
>>
>> The problem is in buildconf.sh: I have fixed it.
>>
>> If you leave autom4te.cache in the distribution and someone makes
>> automake using a different automake than the one you have used when
>> preparing the tarball *very* strange things will happend...
>
>
>
> And for the portable.h was could we do ?
Adding portable.hnw for netware and portable.hw for windoze and #ifdef for AS400
is the clean way.
The quick way is adding:
+++
#if !defined(WIN32) && !defined(AS400) && !defined(NETWARE)
#include "portable.h"
#endif
+++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> jean-frederic clere wrote:
>>
>>> Henri Gomez wrote:
>>>
>>>> Günter Knauf wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I've just tried to build on Linux, and it breaks in jki_connect.c
>>>>> on two boxes, SuSE 7.2 and SuSE9, on the first because no
>>>>> in_addr_t, on the second because its defined as struct and not ulong;
>>>>> furthermore I had exactly the same issue with another project, and
>>>>> we killed in_addr_t usage.
>>>>> If you do a Google for in_addr_t you can directly see that this is
>>>>> a problem on many platforms, seems to me that some have it defined
>>>>> as unsigned long, others as struct, and the rest doesnt have it
>>>>> defined at all...
>>>>> I will this weekend examine this further, unless someone beats me...
>>>>>
>>>>> but I think this is a big showstopper, and we should probably hold
>>>>> the release until this is fixed...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Well I didn't have this problem on the 3 differents Liux distros :
>>>>
>>>> - Fedora Core 2
>>>>
>>>> - Suse 9.0 (i386)
>>>>
>>>> - Suse 8.0 (PPC)
>>>
>>>
>>>
>>>
>>> I see another problem autom4te.cache should be removed before doing
>>> the tarball.
>>
>>
>>
>> I run the buildconf.sh. May be that's the problem ?
>
>
> The problem is in buildconf.sh: I have fixed it.
>
> If you leave autom4te.cache in the distribution and someone makes
> automake using a different automake than the one you have used when
> preparing the tarball *very* strange things will happend...
And for the portable.h was could we do ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> jean-frederic clere wrote:
>
>> Henri Gomez wrote:
>>
>>> Günter Knauf wrote:
>>>
>>>> Hi,
>>>>
>>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>>
>>>>
>>>>
>>>>
>>>> I've just tried to build on Linux, and it breaks in jki_connect.c on
>>>> two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on
>>>> the second because its defined as struct and not ulong;
>>>> furthermore I had exactly the same issue with another project, and
>>>> we killed in_addr_t usage.
>>>> If you do a Google for in_addr_t you can directly see that this is a
>>>> problem on many platforms, seems to me that some have it defined as
>>>> unsigned long, others as struct, and the rest doesnt have it defined
>>>> at all...
>>>> I will this weekend examine this further, unless someone beats me...
>>>>
>>>> but I think this is a big showstopper, and we should probably hold
>>>> the release until this is fixed...
>>>
>>>
>>>
>>>
>>> Well I didn't have this problem on the 3 differents Liux distros :
>>>
>>> - Fedora Core 2
>>>
>>> - Suse 9.0 (i386)
>>>
>>> - Suse 8.0 (PPC)
>>
>>
>>
>> I see another problem autom4te.cache should be removed before doing
>> the tarball.
>
>
> I run the buildconf.sh. May be that's the problem ?
The problem is in buildconf.sh: I have fixed it.
If you leave autom4te.cache in the distribution and someone makes automake using
a different automake than the one you have used when preparing the tarball
*very* strange things will happend...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> Günter Knauf wrote:
>>
>>> Hi,
>>>
>>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>>
>>>
>>>
>>> I've just tried to build on Linux, and it breaks in jki_connect.c on
>>> two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on
>>> the second because its defined as struct and not ulong;
>>> furthermore I had exactly the same issue with another project, and we
>>> killed in_addr_t usage.
>>> If you do a Google for in_addr_t you can directly see that this is a
>>> problem on many platforms, seems to me that some have it defined as
>>> unsigned long, others as struct, and the rest doesnt have it defined
>>> at all...
>>> I will this weekend examine this further, unless someone beats me...
>>>
>>> but I think this is a big showstopper, and we should probably hold
>>> the release until this is fixed...
>>
>>
>>
>> Well I didn't have this problem on the 3 differents Liux distros :
>>
>> - Fedora Core 2
>>
>> - Suse 9.0 (i386)
>>
>> - Suse 8.0 (PPC)
>
>
> I see another problem autom4te.cache should be removed before doing the
> tarball.
I run the buildconf.sh. May be that's the problem ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Günter Knauf wrote:
>
>> Hi,
>>
>>> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>>
>>
>> I've just tried to build on Linux, and it breaks in jki_connect.c on
>> two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on
>> the second because its defined as struct and not ulong;
>> furthermore I had exactly the same issue with another project, and we
>> killed in_addr_t usage.
>> If you do a Google for in_addr_t you can directly see that this is a
>> problem on many platforms, seems to me that some have it defined as
>> unsigned long, others as struct, and the rest doesnt have it defined
>> at all...
>> I will this weekend examine this further, unless someone beats me...
>>
>> but I think this is a big showstopper, and we should probably hold the
>> release until this is fixed...
>
>
> Well I didn't have this problem on the 3 differents Liux distros :
>
> - Fedora Core 2
>
> - Suse 9.0 (i386)
>
> - Suse 8.0 (PPC)
I see another problem autom4te.cache should be removed before doing the tarball.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Henri Gomez <hg...@apache.org>.
Günter Knauf wrote:
> Hi,
>
>>http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
>
> I've just tried to build on Linux, and it breaks in jki_connect.c on two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on the second because its defined as struct and not ulong;
> furthermore I had exactly the same issue with another project, and we killed in_addr_t usage.
> If you do a Google for in_addr_t you can directly see that this is a problem on many platforms, seems to me that some have it defined as unsigned long, others as struct, and the rest doesnt have it defined at all...
> I will this weekend examine this further, unless someone beats me...
>
> but I think this is a big showstopper, and we should probably hold the release until this is fixed...
Well I didn't have this problem on the 3 differents Liux distros :
- Fedora Core 2
- Suse 9.0 (i386)
- Suse 8.0 (PPC)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged - showstopper
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
I've just tried to build on Linux, and it breaks in jki_connect.c on two boxes, SuSE 7.2 and SuSE9, on the first because no in_addr_t, on the second because its defined as struct and not ulong;
furthermore I had exactly the same issue with another project, and we killed in_addr_t usage.
If you do a Google for in_addr_t you can directly see that this is a problem on many platforms, seems to me that some have it defined as unsigned long, others as struct, and the rest doesnt have it defined at all...
I will this weekend examine this further, unless someone beats me...
but I think this is a big showstopper, and we should probably hold the release until this is fixed...
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> Henri Gomez wrote:
>
>> I'll tag jk 1.2.6 by 17h CET.
>>
>> So if you have any showstopper, send me an email :)))
>
>
> JTC tagged as JK_1_2_6
>
> Now back to jk 1.2.7-dev
>
> tarball to be released soon.
Source tarballs available at :
http://jakarta.apache.org/~hgomez/jakarta-tomcat-connectors-jk-1.2.6/
Thanks to check and make some binaries.
PS: Mladen I'm more than interested in the Windows binaries for
Apache 2.0.50
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> I'll tag jk 1.2.6 by 17h CET.
>
> So if you have any showstopper, send me an email :)))
JTC tagged as JK_1_2_6
Now back to jk 1.2.7-dev
tarball to be released soon.
Thanks to various commiters to provide the usual
binaries...
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
jk 1.2.6 to be tagged
Posted by Henri Gomez <hg...@apache.org>.
I'll tag jk 1.2.6 by 17h CET.
So if you have any showstopper, send me an email :)))
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Fernando R. Torrijos wrote:
> Please help me to unsubscribe me from the tomcat and
> relatives forum. I already send a lot of mails to the
> mayordomo with the words unsubscribe but im still
> receiving mail. Please help me.
Please follow the instructions at the bottom of the emails you have
received, which are:
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Regards,
Graham
--
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by "Fernando R. Torrijos" <ft...@yahoo.com>.
Please help me to unsubscribe me from the tomcat and
relatives forum. I already send a lot of mails to the
mayordomo with the words unsubscribe but im still
receiving mail. Please help me.
thanks
fernando R Torrijos
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
> Can you look at the comments at
> http://issues.apache.org/bugzilla/show_bug.cgi?id=30260 -
> apparently this may be a Windows specific problem.
>
Could be, or not.
If for example after connect I write:
if (rv == 730048) {
apr_socket_close(*newsock);
*newsock = NULL;
continue;
}
It goes in an infinite loop, but it should not.
> I'm a unix type, so the windows issues are not something I am
> familiar with.
>
Think that has nothing to do with windows (I even lowered the thread count
to 50), but not sure.
If someone wishes to check that on some worker mpm with high thread count.
It serves 1995 conections, either ab -n 2000 or 2 x ab -n 1000 (the first
one has no errors, the second has 5 errors).
After that any attempt to connect to mod_proxy returns 503.
I've spend couple of hours trying to find the bug, or at least the reason,
but I'm slightly loosing the interest.
Regards,
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> If you turn the loglevel to debug then there is no error messages (although
> everything is by the order of magnitude slower), so the closing algorithm is
> correct.
> The problem is IMHO that you are using a socket (presuming it is free) still
> served by the bucket brigade, but I may be wrong.
>
> MT.
Can you look at the comments at
http://issues.apache.org/bugzilla/show_bug.cgi?id=30260 - apparently
this may be a Windows specific problem.
I'm a unix type, so the windows issues are not something I am familiar with.
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
> > used for an existing socket, or a socket that was not
> closed properly, or one that is still in the process of closing.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > For server applications that need to bind multiple sockets
> to the same
> > port number, consider using setsockopt (SO_REUSEADDR).
>
> Could this be the problem? Maybe proxy is not closing sockets
> properly.
>
If you turn the loglevel to debug then there is no error messages (although
everything is by the order of magnitude slower), so the closing algorithm is
correct.
The problem is IMHO that you are using a socket (presuming it is free) still
served by the bucket brigade, but I may be wrong.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> OS error 10048 means:
>
> Typically, only one usage of each socket address (protocol/IP address/port) is
> permitted. This error occurs if an application attempts to bind a socket to an
> IP address/port that has already been used for an existing socket, or a socket
> that was not closed properly, or one that is still in the process of closing.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> For server applications that need to bind multiple sockets to the same port
> number, consider using setsockopt (SO_REUSEADDR).
Could this be the problem? Maybe proxy is not closing sockets properly.
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
>
> So if I committed the above patch to httpd v2.1.0-dev would
> you be in a position to test it?
>
No, I've tested it.
Still has the same error messages.
OS error 10048 means:
Typically, only one usage of each socket address (protocol/IP address/port) is
permitted. This error occurs if an application attempts to bind a socket to an
IP address/port that has already been used for an existing socket, or a socket
that was not closed properly, or one that is still in the process of closing.
For server applications that need to bind multiple sockets to the same port
number, consider using setsockopt (SO_REUSEADDR).
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> All are exactly the same:
>
> [error] (OS 10048)Only one usage of each socket address (protocol/network
> address/port) is normally permitted. : proxy: HTTP: attempt to connect to
> 127.0.0.1:8080 (localhost) failed
Ok.
> We had a same problen in jk for over two years now. The problem is that you
> will need at least:
>
> Line 1037 in proxy_util.c:
>
> /* make the connection out of the socket */
> do {
> rv = apr_socket_connect(*newsock, backend_addr);
> } while (APR_STATUS_IS_EINTR(rv));
>
>
> But again it might be just an attemp to connect to an nonclosed connection
> (as BTW the error suggests), or perhaps connection beeing in the process of
> disconnection, but cause of high load you have a race condition.
So if I committed the above patch to httpd v2.1.0-dev would you be in a
position to test it?
Regards,
Graham
--
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> We had a same problen in jk for over two years now. The problem is that you
> will need at least:
>
> Line 1037 in proxy_util.c:
>
> /* make the connection out of the socket */
> do {
> rv = apr_socket_connect(*newsock, backend_addr);
> } while (APR_STATUS_IS_EINTR(rv));
Added to bugzilla as 30260.
Regards,
Graham
--
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> /* make the connection out of the socket */
> do {
> rv = apr_socket_connect(*newsock, backend_addr);
> } while (APR_STATUS_IS_EINTR(rv));
One further question (I am not 100% clued up on the workings of apr's
socket handling) - would a situation ever arise where
APR-STATUS_IS_EINTR(rv) would always return non zero, causing an
infinite loop?
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
> Mladen Turk wrote:
>
> > BTW, the errors reported comes from mod_proxy.
>
> What are the errors though, and do they come from mod_proxy
> or mod_proxy_http?
>
All are exactly the same:
[error] (OS 10048)Only one usage of each socket address (protocol/network
address/port) is normally permitted. : proxy: HTTP: attempt to connect to
127.0.0.1:8080 (localhost) failed
> It would be a huge help to the people using proxy (ie for non
> tomcat related stuff) if we could find and fix these error
> conditions under load.
>
We had a same problen in jk for over two years now. The problem is that you
will need at least:
Line 1037 in proxy_util.c:
/* make the connection out of the socket */
do {
rv = apr_socket_connect(*newsock, backend_addr);
} while (APR_STATUS_IS_EINTR(rv));
But again it might be just an attemp to connect to an nonclosed connection
(as BTW the error suggests), or perhaps connection beeing in the process of
disconnection, but cause of high load you have a race condition.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> BTW, the errors reported comes from mod_proxy.
What are the errors though, and do they come from mod_proxy or
mod_proxy_http?
It would be a huge help to the people using proxy (ie for non tomcat
related stuff) if we could find and fix these error conditions under load.
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> >
> > Very strange and totally unusable at least on WIN32.
>
> Well ab running on Win32 didn't very stable ;(
>
Yeah, sure :)
WTF then mod_jk doesn't produce such errors ?
BTW, the errors reported comes from mod_proxy.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
> jean-frederic clere wrote:
>
>>>[error] (OS 10048)Only one usage of each socket address
>>>(protocol/network
>>>address/port) is normally permitted. : proxy: HTTP: attempt to
>>>connect to 127.0.0.1:8080 (localhost) failed
>>>
>>>Anyone has a clue where and why those error messages comes from?
>>
>>Could you try ab -k? - mod_proxy will reuse the socket -
>>
>
>
> Still the same messages.
> When running ab on the same host where apache and TC are located I'm getting
> between 3-16 errors on '-n 1000',
> But when using remote machine and use the ab from remote I'm getting around
> 50% error requests; cca. 450 - 520 requests gets failed.
> The number of failed requests gets lower and lower when I run same ab in a
> series, and it get more and more random, varying from 0 - 50 %.
> Interesting is that rising concurrency level to 20 or more, lowers the error
> number, but It's still around 10% (1120 from 10000 request are 502).
>
> Very strange and totally unusable at least on WIN32.
Well ab running on Win32 didn't very stable ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
jean-frederic clere wrote:
> >
> > [error] (OS 10048)Only one usage of each socket address
> > (protocol/network
> > address/port) is normally permitted. : proxy: HTTP: attempt to
> > connect to 127.0.0.1:8080 (localhost) failed
> >
> > Anyone has a clue where and why those error messages comes from?
>
> Could you try ab -k? - mod_proxy will reuse the socket -
>
Still the same messages.
When running ab on the same host where apache and TC are located I'm getting
between 3-16 errors on '-n 1000',
But when using remote machine and use the ab from remote I'm getting around
50% error requests; cca. 450 - 520 requests gets failed.
The number of failed requests gets lower and lower when I run same ab in a
series, and it get more and more random, varying from 0 - 50 %.
Interesting is that rising concurrency level to 20 or more, lowers the error
number, but It's still around 10% (1120 from 10000 request are 502).
Very strange and totally unusable at least on WIN32.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mladen Turk wrote:
>>Ab -n 10000
>>
>>Time taken for tests: 239.614549 seconds
>>Complete requests: 10000
>>Failed requests: 7011
>>
>>So, mod_proxy is a lot slower and doesn't handle load.
>>(Perhaps increasing http listeners on TC would help).
>>
>
>
> Increasing the maxThreads to 350 and acceptCount to 300 doesn't solve the
> issue.
> On large load I'm getting the following using mod_proxy:
>
> [error] (OS 10048)Only one usage of each socket address (protocol/network
> address/port) is normally permitted. : proxy: HTTP: attempt to connect to
> 127.0.0.1:8080 (localhost) failed
>
> Anyone has a clue where and why those error messages comes from?
Could you try ab -k? - mod_proxy will reuse the socket -
>
> MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
>
> Ab -n 10000
>
> Time taken for tests: 239.614549 seconds
> Complete requests: 10000
> Failed requests: 7011
>
> So, mod_proxy is a lot slower and doesn't handle load.
> (Perhaps increasing http listeners on TC would help).
>
Increasing the maxThreads to 350 and acceptCount to 300 doesn't solve the
issue.
On large load I'm getting the following using mod_proxy:
[error] (OS 10048)Only one usage of each socket address (protocol/network
address/port) is normally permitted. : proxy: HTTP: attempt to connect to
127.0.0.1:8080 (localhost) failed
Anyone has a clue where and why those error messages comes from?
MT.
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Remy Maucherat wrote:
> Speaking about performance, did anyone do a comparison of
> mod_proxy against mod_jk to see how good/bad it is ? This is
> really important information IMO, and I don't see how a
> decision can be made without it.
>
Results a quite impressive, good question Remy :)
Tomcat 5.0.27 + Apache 2.0.50
All tests done on a clean startup with empty logs.
ProxyPass /servlets-examples/ http://localhost:8080/servlets-examples/
ProxyPassReverse /servlets-examples/
http://localhost:8080/servlets-examples/
Ab -n 1000
Time taken for tests: 4.226077 seconds
Mod_jk-1.26
JkWorkersFile conf/workers.properties
JkMount /servlets-examples/* ajp13
Time taken for tests: 2.824061 seconds
A lot, lot faster.
What is more interesting is when you increase the number of loops forom 1000
to 10000
Ab -n 10000
Time taken for tests: 239.614549 seconds
Complete requests: 10000
Failed requests: 7011
Using mod_jk:
Ab -n 10000
Time taken for tests: 21.811363 seconds
Complete requests: 10000
Failed requests: 0
So, mod_proxy is a lot slower and doesn't handle load.
(Perhaps increasing http listeners on TC would help).
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by David Rees <dr...@greenhydrant.com>.
Remy Maucherat wrote, On 7/21/2004 11:33 PM:
>
> The changes would have to be simple, and non intrusive performance wise.
> Otherwise, I'm going to prefer AJP ;)
> Speaking about performance, did anyone do a comparison of mod_proxy
> against mod_jk to see how good/bad it is ? This is really important
> information IMO, and I don't see how a decision can be made without it.
I did a couple quick tests using a few different sized static documents
using ab, Tomcat 5.0.27, Apache 2.0.50 both on the same single CPU
machine. Depending on the document size, mod_proxy was anywhere from
50% (very small document of a few bytes) to 10% (30k document) slower
than mod_jk.
By comparison, going directly to Tomcat about twice as fast as using
mod_jk, and going directly to Apache is another 30% faster than that.
Watching CPU utilization when switching between mod_jk and mod_proxy
showed that Tomcat uses a lot more CPU when using mod_proxy than when
using mod_jk.
So while the performance hit isn't negligible, it's not too bad. It
does show that it will be worthwhile to a proxy_ajp_module, but at the
same time I think that using plain http provides more than enough
performance for the majority of users out there, and you can't argue
with the fact that the work will benefit a lot more than just Tomcat and
lessen development time.
I could see people using the proposed load-balancing functionality along
with mod_proxy to balance requests to clusters of many other application
servers (PHP, perl, CGI, etc) as well.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Tim Funk wrote:
> *Changes to tomcat*
> Add a proxy mode flag to allow for the X- headers to pass
> authentication and other variables.
> Add to the manager(?) app and method to expose all the URL spaces
> availble.
> Minor changes to fix getRemoteAddr() to show the client, not the
> apache server.
>
>
> Pros - Simple(?) and not tomcat specific.
> Cons - Duplicate (re)parsing of headers, probably higher latency than jk.
The changes would have to be simple, and non intrusive performance wise.
Otherwise, I'm going to prefer AJP ;)
Speaking about performance, did anyone do a comparison of mod_proxy
against mod_jk to see how good/bad it is ? This is really important
information IMO, and I don't see how a decision can be made without it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Tim Funk wrote:
> I'm not sure of the status so far, but I'd like to summarize a strawman.
> I have no idea how to code this at this time or if it can be done.
No problem, we drill down into the details as we go along :)
> *Config* [Feel free to change the names]
> ProxyClient http://server1/config.xml
> ProxyClient http://server2/config.xml
> ProxyClient http://server3/another/config.xml
> ProxyUpdate /proxyconfig
The config should follow the established config for proxy, which would
be this:
ProxyPass /myWebapp ajp://server1/myWebapp
At the moment, "server1" would resolve to multiple names, however a
userful addition would be ability to do this:
ProxyPass /myWebapp ajp://server1 server2 server3/myWebapp
which is the way LDAP URLs handle multiple possible servers.
> *Startup*
> Apache polls each proxy-client for existence and config at the URL
> defined by te ProxyClient directive.
> Each proxy-client states the paths/extension/mimetype/??? it can serve
> as well as its "weight".
It is the job of proxy_ajp to understand what "ajp://server1 server2
server3/myWebapp" means.
What proxy_ajp can do, if it has not already done so, is poll the
servers in the server list and say "hey guys, which of you lot serves
myWebapp? All of you? Ok cool bananas - the top of the list of IPs I
have been given is you server1, so go ahead, knock yourself out".
> *On going*
> Apache periodically polls the config URL for changes.
> --or--
> A proxy-client can join, remove, alter URL availability by using making a
> request to apache defined at ProxyUpdate.
proxy_ajp need not poll - it can do so as the request arrives.
If proxy_ajp connects to the backend, and that backend returns 5xx, then
proxy_ajp says "Oops, obviously not serving any more, let me try the
next IP in my list and see if that one is willing to serve my request".
> *Edge cases*
> Authentication, environment variables, and other system parameters would be
> passed to the proxy via X-Headers. Apache would need to deny/filter
> these header names from outside clients.
I don't understand - are these headers created by tomcat, and passed
towards the client, or created by the client, and passed towards tomcat?
Either way, funky header handling would be done by proxy_ajp.
> *stickyness*
> unknown how to fix this in a generic manner
Using a completely separate and independant module called
"proxy_sticky", which uses a hook I will be putting into proxy sometime
this weekend. :)
> *Failover* 2 cases
> 1) server unavailable - easy to recover since a new connection is made
> 2) server available but doesn't handle request anymore -
> Proxy-client returns a custom header to let apache move to next node?
No need for a custom header - just interpret the response codes
correctly. 5xx means try the next server in the list, if you run out of
list, pass the error back up to the client.
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by "Filip Hanik (lists)" <de...@hanik.com>.
added to summarization, missing stickiness
1. Set a cookie on the clients machine - no server memory to hold a map
2. If the client doesn't accept cookies, do a simple sticky load balancing
based on the IP of the client request. Again, no memory map needed.
-----Original Message-----
From: Tim Funk [mailto:funkman@joedog.org]
Sent: Wednesday, July 21, 2004 8:17 PM
To: Tomcat Developers List
Subject: Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in
tomcat-dev
I'm not sure of the status so far, but I'd like to summarize a strawman. I
have no idea how to code this at this time or if it can be done.
--------------------------
*Config* [Feel free to change the names]
ProxyClient http://server1/config.xml
ProxyClient http://server2/config.xml
ProxyClient http://server3/another/config.xml
ProxyUpdate /proxyconfig
*Startup*
Apache polls each proxy-client for existence and config at the URL defined
by
te ProxyClient directive.
Each proxy-client states the paths/extension/mimetype/??? it can serve as
well as its "weight".
*On going*
Apache periodically polls the config URL for changes.
--or--
A proxy-client can join, remove, alter URL availability by using making a
request to apache defined at ProxyUpdate.
*Edge cases*
Authentication, environment variables, and other system parameters would be
passed to the proxy via X-Headers. Apache would need to deny/filter these
header names from outside clients.
*stickyness*
unknown how to fix this in a generic manner
*Failover* 2 cases
1) server unavailable - easy to recover since a new connection is made
2) server available but doesn't handle request anymore -
Proxy-client returns a custom header to let apache move to next node?
*Changes to tomcat*
Add a proxy mode flag to allow for the X- headers to pass authentication and
other variables.
Add to the manager(?) app and method to expose all the URL spaces availble.
Minor changes to fix getRemoteAddr() to show the client, not the apache
server.
Pros - Simple(?) and not tomcat specific.
Cons - Duplicate (re)parsing of headers, probably higher latency than jk.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Tim Funk <fu...@joedog.org>.
I'm not sure of the status so far, but I'd like to summarize a strawman. I
have no idea how to code this at this time or if it can be done.
--------------------------
*Config* [Feel free to change the names]
ProxyClient http://server1/config.xml
ProxyClient http://server2/config.xml
ProxyClient http://server3/another/config.xml
ProxyUpdate /proxyconfig
*Startup*
Apache polls each proxy-client for existence and config at the URL defined by
te ProxyClient directive.
Each proxy-client states the paths/extension/mimetype/??? it can serve as
well as its "weight".
*On going*
Apache periodically polls the config URL for changes.
--or--
A proxy-client can join, remove, alter URL availability by using making a
request to apache defined at ProxyUpdate.
*Edge cases*
Authentication, environment variables, and other system parameters would be
passed to the proxy via X-Headers. Apache would need to deny/filter these
header names from outside clients.
*stickyness*
unknown how to fix this in a generic manner
*Failover* 2 cases
1) server unavailable - easy to recover since a new connection is made
2) server available but doesn't handle request anymore -
Proxy-client returns a custom header to let apache move to next node?
*Changes to tomcat*
Add a proxy mode flag to allow for the X- headers to pass authentication and
other variables.
Add to the manager(?) app and method to expose all the URL spaces availble.
Minor changes to fix getRemoteAddr() to show the client, not the apache server.
Pros - Simple(?) and not tomcat specific.
Cons - Duplicate (re)parsing of headers, probably higher latency than jk.
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
Filip Hanik - Dev wrote:
> I didn't say anything about "just simple round robin"
> the algorithm for distribution can be entirely separate from the "stickiness" as they are two separate things. The distribution
> algorithm, (round ron, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one
> server, I should go to that server again and again until that server fails or meets another criteria to not receive requests.
And this "another criteria" is a _very_ important use case ( and one of
the reasons I am insisting on having some form of dynamic
configuration/jmx/whatever ).
Many large servers ( banks, etc ) would not want to lose client sessions
when they upgrade a worker in the pool - so they need to be able to tell
that a particular instance should not be included in the "round robin"
for new sessions, but only get the requests from previous sessions.
They also need to be able to add more workers, or remove some workers
from the pool.
I know, the jk implementation is very ugly - but IMO this use case is
quite important and it shouldn't be lost.
Costin
>
> Filip
>
> ----- Original Message -----
> From: "Mladen Turk" <mt...@apache.org>
> To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
> Sent: Wednesday, July 21, 2004 11:30 AM
> Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
>
>
>
>
> Filip Hanik wrote:
>
>>The current jvmRoute addition to JSESSIONID is not really
>>needed, since it doesn't add that much of a benefit over the
>>two options above. So right then and there, there is one less
>>thing to configure.
>>
>
>
> Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance
> load factor, not just sticky sessions and simple round robin.
> Also the JSESSIONID then does not to be harcoded, but rather configurable.
>
> MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Viktor Hevesi <vi...@oddych.sk>.
Dobry den,
nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu
"NIE SPAM" a znova ho poslite. V buducich mailoch uz "NIE SPAM" pisat
nemusite.
Antispamovy filter Oddych.sk
Nedoruceny mail:
GL> Mladen Turk wrote:
>> Ok, just wanted to clear if we are going to make another compromise :),
>> since sticky sessions are tightly coupled with the load balancer itself and
>> the way it decides the client route.
GL> In theory sticky sessions shouldn't be tightly coupled like this - it
GL> should be a case of "plan a) stick to the same server, else revert to
GL> plan b)".
GL> In this case plan B could be simple DNS round robin, or it could be a
GL> load balancer, in other words another module entirely.
GL> This raises a question - what order do the modules run in? In theory the
GL> sticky module should run last, in other words a load balancer (or DNS
GL> round robin, or whatever) orders the IPs based on some criteria (load,
GL> or round robin, or whatever), and then the sticky module takes the
GL> sticky server identified by the cookie/parameter and moves that sticky
GL> IP on top of the list.
GL> I suppose in this case the load balancer would run HOOK_MIDDLE, and
GL> sticky would run HOOK_LAST.
GL> Regards,
GL> Graham
GL> --
-=x=-
Skontrolovan� antiv�rov�m programom NOD32
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Viktor Hevesi <vi...@oddych.sk>.
Dobry den,
nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu
"NIE SPAM" a znova ho poslite. V buducich mailoch uz "NIE SPAM" pisat
nemusite.
Antispamovy filter Oddych.sk
Nedoruceny mail:
MT> Graham Leggett wrote:
>> > sticky sessions are tightly coupled with the load
>> balancer
>> > itself and the way it decides the client route.
>>
>> In theory sticky sessions shouldn't be tightly coupled like
>> this - it should be a case of "plan a) stick to the same
>> server, else revert to plan b)".
>>
MT> Yes, but why would you wish to separate those?
MT> The stickiness is the part of load balancer, and merely flags the connection
MT> to a particular remote so that the load balancer can skip the Remote
MT> selection, cause it already selected the Remote in some previous
MT> transaction.
MT> Something different is the way the load balancer selects the Remote, and
MT> that can be separated if the separation is needed at all, but I doubt that.
>>
>> I suppose in this case the load balancer would run
>> HOOK_MIDDLE, and sticky would run HOOK_LAST.
>>
MT> I'm not that familiar with mod_proxy code, so please no hooks, not jet :)
MT> MT.
-=x=-
Skontrolovan� antiv�rov�m programom NOD32
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Filip Hanik - Dev wrote:
>>I suppose in this case the load balancer would run HOOK_MIDDLE, and
>>sticky would run HOOK_LAST.
> cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the
> list (and that list should be ordered well since it comes from the LB algorithm)
>
> correct assumption?
Yes.
In other words, you start with a list of IPs (supplied by the config,
resolved by DNS), and each "load balancer" module reorders the IP
addresses in turn, as needed.
So a load balancer module will reorder the IPs least loaded to most loaded.
Then the sticky module will either do nothing to list, or it will notice
a sticky session, and move the sticky IP address to the top of the list.
Thing is for the sticky module to be effective, it must run last,
otherwise the load balancer will undo sticky's work.
Regards,
Graham
--
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Viktor Hevesi <vi...@oddych.sk>.
Dobry den,
nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu
"NIE SPAM" a znova ho poslite. V buducich mailoch uz "NIE SPAM" pisat
nemusite.
Antispamovy filter Oddych.sk
Nedoruceny mail:
>>I suppose in this case the load balancer would run HOOK_MIDDLE, and
>>sticky would run HOOK_LAST.
FHD> cool, and then have the server just try them in that order?
FHD> ie, if the sticky server went down, it just takes the next one
FHD> from the
FHD> list (and that list should be ordered well since it comes from the LB algorithm)
FHD> correct assumption?
FHD> Filip
FHD> ----- Original Message -----
FHD> From: "Mladen Turk" <mt...@apache.org>
FHD> To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
FHD> Sent: Wednesday, July 21, 2004 1:12 PM
FHD> Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
FHD> Graham Leggett wrote:
>>
>> > Yes, but why would you wish to separate those?
>>
>> Because they are two separate behaviours that could quite
>> easily be used independantly of each other.
>>
FHD> OK, it makes sense.
>>
>> > I'm not that familiar with mod_proxy code, so please no
>> hooks, not jet
>> > :)
>>
>> I am familiar with the code, so don't be afraid of the hooks,
>> as I'm quite willing to tell you where things go :)
>>
FHD> So, where do you see a lb code in the mod_proxy tree. Do you have some ideas
FHD> where will it fit?
FHD> It would be also good if you could make some p-code of the mod_proxy or some
FHD> data flow diagram.
FHD> Also do you need our support on coding?
FHD> It would be perhaps better that you write the function prototypes that need
FHD> some lb behavior returnig somethig like not_implemented or just mark some /*
FHD> TODO: ...*/ in the code.
FHD> MT.
FHD> ---------------------------------------------------------------------
FHD> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
FHD> For additional commands, e-mail:
FHD> tomcat-dev-help@jakarta.apache.org
-=x=-
Skontrolovan� antiv�rov�m programom NOD32
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
jean-frederic clere wrote:
>
> I am looking to get the sessionid:
> - By reading request_rec->unparsed_uri or request_rec->uri.
> - By reading the cooky from request_rec->headers_in.
>
> How do I read the sessionid in the response?
>
Good point. We'll need something like mod_proxy_html or something like that to
parse the headers returned from Remote.
Cannot speak for sure, cause I still have some problems figuring out the
mod_proxy algorithm.
It's getting more and more complicated :).
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mladen Turk wrote:
>
>
> Filip Hanik wrote:
>
>>really, so then there is no fail over.
>
>
> Yes there are. In Jk default is to fail over always.
> The JK2 has a routeRedirect to handle such cases (but not strictly).
> If the routeRedirect is down it will still fail over, which is probably
> incorrect.
>
>
>>cause that is what fail over does, redirects you to another server.
>>and with session replication in place, you should be good to go
>>
>
>
> Sure if you've set up many-to-many session replication.
>
> We should have something like:
>
> If we have a session route but the worker is down
> If there is a routeRedirect then
> If the routeRedirect worker is down
> return 500
> Else
> return routeRedirect
> Else
> Fail over to another worker
> Else
> return sessionWorker
>
> Basically it means that if the redirection worker is down don't fail over,
> but rather break the transaction.
>
> It enables single session replication node.
>
> I don't care if the fail over will be turned on by default or not, but would
> like to have a control in cases where either there are:
>
> A) session replication is in place on all nodes
> B) session replication is done on a single node
> C) there is no session replication at all
>
> Like said the JK presumes there is A, JK2 handles both A and B cases (but it
> should C too).
>
> MT.
I am looking to get the sessionid:
- By reading request_rec->unparsed_uri or request_rec->uri.
- By reading the cooky from request_rec->headers_in.
How do I read the sessionid in the response?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Filip Hanik wrote:
>
> really, so then there is no fail over.
Yes there are. In Jk default is to fail over always.
The JK2 has a routeRedirect to handle such cases (but not strictly).
If the routeRedirect is down it will still fail over, which is probably
incorrect.
> cause that is what fail over does, redirects you to another server.
> and with session replication in place, you should be good to go
>
Sure if you've set up many-to-many session replication.
We should have something like:
If we have a session route but the worker is down
If there is a routeRedirect then
If the routeRedirect worker is down
return 500
Else
return routeRedirect
Else
Fail over to another worker
Else
return sessionWorker
Basically it means that if the redirection worker is down don't fail over,
but rather break the transaction.
It enables single session replication node.
I don't care if the fail over will be turned on by default or not, but would
like to have a control in cases where either there are:
A) session replication is in place on all nodes
B) session replication is done on a single node
C) there is no session replication at all
Like said the JK presumes there is A, JK2 handles both A and B cases (but it
should C too).
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Filip Hanik - Dev <de...@hanik.com>.
really, so then there is no fail over.
cause that is what fail over does, redirects you to another server.
and with session replication in place, you should be good to go
FIlip
----- Original Message -----
From: "Mladen Turk" <mt...@apache.org>
To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
Sent: Wednesday, July 21, 2004 2:00 PM
Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote:
>
> >I suppose in this case the load balancer would run HOOK_MIDDLE, and
> >sticky would run HOOK_LAST.
>
> cool, and then have the server just try them in that order?
> ie, if the sticky server went down, it just takes the next
> one from the list (and that list should be ordered well since
> it comes from the LB algorithm)
>
> correct assumption?
>
Think that it should return 'Server Busy' in case the sticky is not
available, cause you may be in the middle of transaction while the other
server might have no clue about that.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Filip Hanik wrote:
>
> >I suppose in this case the load balancer would run HOOK_MIDDLE, and
> >sticky would run HOOK_LAST.
>
> cool, and then have the server just try them in that order?
> ie, if the sticky server went down, it just takes the next
> one from the list (and that list should be ordered well since
> it comes from the LB algorithm)
>
> correct assumption?
>
Think that it should return 'Server Busy' in case the sticky is not
available, cause you may be in the middle of transaction while the other
server might have no clue about that.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Filip Hanik - Dev <de...@hanik.com>.
>I suppose in this case the load balancer would run HOOK_MIDDLE, and
>sticky would run HOOK_LAST.
cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the
list (and that list should be ordered well since it comes from the LB algorithm)
correct assumption?
Filip
----- Original Message -----
From: "Mladen Turk" <mt...@apache.org>
To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
Sent: Wednesday, July 21, 2004 1:12 PM
Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote:
>
> > Yes, but why would you wish to separate those?
>
> Because they are two separate behaviours that could quite
> easily be used independantly of each other.
>
OK, it makes sense.
>
> > I'm not that familiar with mod_proxy code, so please no
> hooks, not jet
> > :)
>
> I am familiar with the code, so don't be afraid of the hooks,
> as I'm quite willing to tell you where things go :)
>
So, where do you see a lb code in the mod_proxy tree. Do you have some ideas
where will it fit?
It would be also good if you could make some p-code of the mod_proxy or some
data flow diagram.
Also do you need our support on coding?
It would be perhaps better that you write the function prototypes that need
some lb behavior returnig somethig like not_implemented or just mark some /*
TODO: ...*/ in the code.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
>
> > Yes, but why would you wish to separate those?
>
> Because they are two separate behaviours that could quite
> easily be used independantly of each other.
>
OK, it makes sense.
>
> > I'm not that familiar with mod_proxy code, so please no
> hooks, not jet
> > :)
>
> I am familiar with the code, so don't be afraid of the hooks,
> as I'm quite willing to tell you where things go :)
>
So, where do you see a lb code in the mod_proxy tree. Do you have some ideas
where will it fit?
It would be also good if you could make some p-code of the mod_proxy or some
data flow diagram.
Also do you need our support on coding?
It would be perhaps better that you write the function prototypes that need
some lb behavior returnig somethig like not_implemented or just mark some /*
TODO: ...*/ in the code.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> Yes, but why would you wish to separate those?
Because they are two separate behaviours that could quite easily be used
independantly of each other.
I would probably use the stickiness long before I started messing around
with load balancing.
> I'm not that familiar with mod_proxy code, so please no hooks, not jet :)
I am familiar with the code, so don't be afraid of the hooks, as I'm
quite willing to tell you where things go :)
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
> > sticky sessions are tightly coupled with the load
> balancer
> > itself and the way it decides the client route.
>
> In theory sticky sessions shouldn't be tightly coupled like
> this - it should be a case of "plan a) stick to the same
> server, else revert to plan b)".
>
Yes, but why would you wish to separate those?
The stickiness is the part of load balancer, and merely flags the connection
to a particular remote so that the load balancer can skip the Remote
selection, cause it already selected the Remote in some previous
transaction.
Something different is the way the load balancer selects the Remote, and
that can be separated if the separation is needed at all, but I doubt that.
>
> I suppose in this case the load balancer would run
> HOOK_MIDDLE, and sticky would run HOOK_LAST.
>
I'm not that familiar with mod_proxy code, so please no hooks, not jet :)
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> Ok, just wanted to clear if we are going to make another compromise :),
> since sticky sessions are tightly coupled with the load balancer itself and
> the way it decides the client route.
In theory sticky sessions shouldn't be tightly coupled like this - it
should be a case of "plan a) stick to the same server, else revert to
plan b)".
In this case plan B could be simple DNS round robin, or it could be a
load balancer, in other words another module entirely.
This raises a question - what order do the modules run in? In theory the
sticky module should run last, in other words a load balancer (or DNS
round robin, or whatever) orders the IPs based on some criteria (load,
or round robin, or whatever), and then the sticky module takes the
sticky server identified by the cookie/parameter and moves that sticky
IP on top of the list.
I suppose in this case the load balancer would run HOOK_MIDDLE, and
sticky would run HOOK_LAST.
Regards,
Graham
--
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Filip Hanik wrote:
>
> I didn't say anything about "just simple round robin"
> the algorithm for distribution can be entirely separate from
> the "stickiness" as they are two separate things. The
> distribution algorithm, (round robin, load, random, etc) is
> separate and should not be confused. Stickyness means that if
> I have been to one server, I should go to that server again
> and again until that server fails or meets another criteria
> to not receive requests.
>
Ok, just wanted to clear if we are going to make another compromise :),
since sticky sessions are tightly coupled with the load balancer itself and
the way it decides the client route.
MT.
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Filip Hanik - Dev <de...@hanik.com>.
I didn't say anything about "just simple round robin"
the algorithm for distribution can be entirely separate from the "stickiness" as they are two separate things. The distribution
algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one
server, I should go to that server again and again until that server fails or meets another criteria to not receive requests.
Filip
----- Original Message -----
From: "Mladen Turk" <mt...@apache.org>
To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
Sent: Wednesday, July 21, 2004 11:30 AM
Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote:
>
> The current jvmRoute addition to JSESSIONID is not really
> needed, since it doesn't add that much of a benefit over the
> two options above. So right then and there, there is one less
> thing to configure.
>
Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance
load factor, not just sticky sessions and simple round robin.
Also the JSESSIONID then does not to be harcoded, but rather configurable.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Posted by Mladen Turk <mt...@apache.org>.
Filip Hanik wrote:
>
> The current jvmRoute addition to JSESSIONID is not really
> needed, since it doesn't add that much of a benefit over the
> two options above. So right then and there, there is one less
> thing to configure.
>
Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance
load factor, not just sticky sessions and simple round robin.
Also the JSESSIONID then does not to be harcoded, but rather configurable.
MT.