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
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
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
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
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
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
^^
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:
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
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
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 =
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
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
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
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
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
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
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
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 [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent:
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
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
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
55 matches
Mail list logo
