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 =
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 sess
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 b
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 set
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, whi
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!?
Informa
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,
G
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 p
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_
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
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: S/MIME
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 ev
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 returne
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:
> 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 (
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
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/
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
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
^^
/examples/servlet/H
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
gene
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.
Regard
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 i
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
Pr
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 s
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 s
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 fro
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 fro
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
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 30
>
> 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
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
info
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 somet
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
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 :)
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 i
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
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 - Si
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 simp
: Tim Funk [mailto:[EMAIL PROTECTED]
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
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 h
essage -
From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
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 curre
s List'" <[EMAIL PROTECTED]>
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 HOO
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 b
)
FHD> correct assumption?
FHD> Filip
FHD> - Original 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: S
om 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
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
> >
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_pr
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 loa
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 pla
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
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 "pla
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 confu
x27;" <[EMAIL PROTECTED]>
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
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 w
54 matches
Mail list logo
