It seems we didn't got this CC in tc-dev :
---BeginMessage---
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,
Henri Gomez wrote:
It seems we didn't got this CC in tc-dev :
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,
Remy Maucherat wrote, On 7/28/2004 7:54 AM:
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
: David Rees [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, July 28, 2004 11:08 AM
Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in
tomcat-dev]
Remy Maucherat wrote, On 7/28/2004 7:54 AM:
One thing I noticed when looking at Tomcat
Filip Hanik - Dev wrote:
The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The
Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where
Ok. Well, I think
- Original Message -
From: Filip Hanik - Dev [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, July 28, 2004 9:13 AM
Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD
commiters in tomcat-dev]
The Java VM does this through file handling
Remy Maucherat wrote:
Filip Hanik - Dev wrote:
The Java VM does this through file handling, we would have to find
out where it issues this call and if we can get around it. The
Tomcat developers are not calling stat anywhere in the code, but the
underlying JVM code does, we just don't know where
Bill Barker wrote:
My guess would be File.getCanonicalPath() in FileDirContext.
There's a cache for that, so canonicalization will happen only once in a
while. I don't understand how it can possibly be a performance issue.
Rémy
From: Bill Barker [EMAIL PROTECTED]
From: Filip Hanik - Dev [EMAIL PROTECTED]
The Java VM does this through file handling, we would have
to find out where it issues this call and if we can get around it. The
Tomcat developers are not calling stat anywhere in the code, but
the underlying
There's a cache for that, so canonicalization will happen only once in a
while. I don't understand how it can possibly be a performance issue.
maybe I am reading the code wrong, but the method file() in FileDirContext creates a
new file object each time, so there is no
caching there.
So I guess
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 ;(
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
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
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 -
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
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
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 :)
In previous mail I forgot one crucial result:
Ab -n 1000 directly to TC
Time taken for tests: 1.882708 seconds
Ab -n 1 directly to TC
Time taken for tests: 17.244797 seconds
I'll leave the calculation to others.
MT.
smime.p7s
Description: S/MIME cryptographic signature
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
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
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
Ab -n 1
Time taken for tests: 239.614549 seconds
Complete requests: 1
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
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
Mladen Turk wrote:
Ab -n 1
Time taken for tests: 239.614549 seconds
Complete requests: 1
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
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
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?
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
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
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
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.
smime.p7s
Description: S/MIME cryptographic
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
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
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
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
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.
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
jean-frederic clere wrote:
I also I have some (40) errors with concurrency 300 but Tomcat and
Apache are in 2 different machines:
+++
[Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy:
DNS lookup failure for: pgtr0327.mch.fsc.net returned by
^^
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
Graham Leggett wrote:
jean-frederic clere wrote:
I also I have some (40) errors with concurrency 300 but Tomcat and
Apache are in 2 different machines:
+++
[Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy:
DNS lookup failure for: pgtr0327.mch.fsc.net returned by
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)
Remy Maucherat wrote:
+1 on using a real OS ;)
Well, you could also use a real programming language for start ;-).
MT.
smime.p7s
Description: S/MIME cryptographic signature
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
Remy Maucherat wrote:
DNS lookup failure for: pgtr0327.mch.fsc.net returned by
^^
It's not normal there's a DNS lookup on each request. Why does it happen ?
In the config it was set to connect to a DNS name, which has to be
resolved - but httpd doesn't do any caching of this
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
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 [EMAIL PROTECTED] wrote:
Remy Maucherat wrote:
Henri Gomez wrote:
I made some benchs on my Linux
Remy Maucherat wrote:
Graham Leggett wrote:
jean-frederic clere wrote:
I also I have some (40) errors with concurrency 300 but Tomcat and
Apache are in 2 different machines:
+++
[Thu Jul 22 11:39:39 2004] [error] [client 172.25.182.35] proxy:
DNS lookup failure for: pgtr0327.mch.fsc.net
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
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 ;(
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 [EMAIL PROTECTED] wrote:
Peter Lin wrote:
the nightly build of jmeter has an alpha sampler that
jean-frederic clere wrote:
Not for each request but each time http makes a new connection to Tomcat.
We have to cache the result of apr_sockaddr_info_get().
Added to bugzilla as a request for enhancement (so this doesn't fall
through the cracks).
Regards,
Graham
--
smime.p7s
Description:
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
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
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
Graham Leggett wrote:
jean-frederic clere wrote:
Not for each request but each time http makes a new connection to Tomcat.
We have to cache the result of apr_sockaddr_info_get().
Added to bugzilla as a request for enhancement (so this doesn't fall
through the cracks).
That is PR 30259.
Regards,
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!?
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,
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
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
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
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 =
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
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
Hi,
Does wget support HTTP/1.1?
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Henri Gomez [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 22, 2004 12:36 PM
To: Tomcat Developers List
Subject: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in
tomcat
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
Graham Leggett wrote:
Thing is it's easier for end users to not have to mess around
with third party builds if it can possibly be avoided, and
it's the needs of the end users who are the most important,
not the developers.
It was the main reason why we tried to go beyond the concepts
Mladen Turk wrote:
Graham Leggett wrote:
Thing is it's easier for end users to not have to mess around
with third party builds if it can possibly be avoided, and
it's the needs of the end users who are the most important,
not the developers.
It was the main reason why we tried to go beyond
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It makes a big difference to
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It
Henri Gomez wrote:
BTW, could we expect to be able to use in proxy_ajp URL like
ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an
AJP cluster backend ?
That would be up to proxy_ajp to decide, so yes.
What happens is that when the config says
ProxyPass /myApp ajp://VIRTUALNAME
and the
Graham Leggett wrote:
I don't think that it is necessary for a mod_ajp to be
included inside
the mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts
ultimately makes for doing things in a consistent way. It
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It
Mladen Turk wrote:
I think it's very necessary - sharing those common concepts
ultimately makes for doing things in a consistent way. It
makes a big difference to the usability of httpd.
I'm sure that the 'normalization' would lead to nowhere.
I don't follow - what does normalisation would lead
Mladen Turk wrote:
Graham Leggett wrote:
I don't think that it is necessary for a mod_ajp to be
included inside
the mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts
ultimately makes for doing things in a consistent way.
jean-frederic clere wrote:
I see in ap_proxy_http_handler() that DECLINED allows to try another. Is
there somewhere an example of a configuration using it?
ap_proxy_http_handler() is found in mod_proxy_http, which is the helper
module that handles the HTTP protocol in the proxy framework. You
Henri Gomez wrote:
Graham Leggett wrote:
Just rewriting mod_ajp for v2.0 isn't anything different to
what exists now, so I don't see the point.
Well, that's how you see it.
IMO trying again to squize the apache2-Tomcat module
inside some already
present solution would
Mladen Turk wrote:
I think that we forked from jk/jk2 to be able to write from the scratch the
module that will do exactly _one_ and _only_one_ thing; and that is
effectively communicate with TC server using ajp13+ protocol.
So, my question is. Why do we need again some container to accomplish
Graham Leggett wrote:
So, my question is. Why do we need again some container to
accomplish that?
Because the container already gives you an established
configuration method, a standard set of documentation, and a
standard expectation from end users on how it should work.
That's
One thing missing - the proposal to actually just use mod_proxy, with
enhancements for load balancing, and with http as protocol ( i.e. drop
Ajp ).
That would be a real simplification on both sides !
The tiny performance benefit of a binary protocol is really not worth
it. The 'http parsing'
- Original Message -
From: Mladen Turk [EMAIL PROTECTED]
I also see no reason why the mod_proxy functionally cannot be implemented in
mod_jk2 :).
yes, but it is rocket science to actually get jk2 compiled and configured and to work
properly. mod_proxy is part of the core, and
takes
Mladen Turk wrote:
AjpWorker and AjpBalancer for example, or do we need to mimic that inside
the existing configuration directives?
Well the, AjpWorker can be mapped to ProxyRemote if you change it to
ProxyRemote. See my point?
AjpBalancer could be applied to a theoretical proxy_balancer module
Costin Manolache wrote:
One thing missing - the proposal to actually just use mod_proxy, with
enhancements for load balancing, and with http as protocol ( i.e. drop
Ajp ).
That would be a real simplification on both sides !
I also find HTTP to be more than adequate in most cases, but if there
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It
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
Graham Leggett wrote:
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.
Henri Gomez wrote:
Graham Leggett wrote:
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
:27 AM
Subject: Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those
Message -
From: Graham Leggett [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
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
Henri Gomez wrote:
So next step should be to add LB functionalities (with sticky
JSSESSION support) in mod_proxy = Graham ?
There is also a question of development cycle.
Are we gonna develop sending patches or what... Suggestions?
MT.
smime.p7s
Description: S/MIME cryptographic
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
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
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.
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
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
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).
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
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
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
the LB algorithm)
correct assumption?
Filip
- Original Message -
From: Mladen Turk [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 1:12 PM
Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote
Message -
FHD From: Mladen Turk [EMAIL PROTECTED]
FHD To: 'Tomcat Developers List' [EMAIL PROTECTED]
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
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
1 - 100 of 142 matches
Mail list logo
