The below is the workaround for 2.2.6... 2.2.7 contains the
actual fix that negates the need for the workaround :)
On Nov 21, 2007, at 4:34 AM, David Cassidy wrote:
That would be excellent !
Is the only change - as far as mod_proxy_ajp is concerned the one
below
or is that a work around for
That would be excellent !
Is the only change - as far as mod_proxy_ajp is concerned the one below
or is that a work around for 2.2.6 ?
Thanks
D
On Tue, 2007-11-20 at 14:39 -0500, Jim Jagielski wrote:
> I'm hoping to get it out the top of December :)
>
> On Nov 20, 2007, at 3:57 AM, David Cass
I'm hoping to get it out the top of December :)
On Nov 20, 2007, at 3:57 AM, David Cassidy wrote:
Hi Jim !!!
This is fantastic news !
When is 2.2.7 going to be released ?
:)
Many many thanks
David
On Mon, 2007-11-19 at 15:27 -0500, Jim Jagielski wrote:
2.2.6 has a nasty bug were AJP con
Hi Jim !!!
This is fantastic news !
When is 2.2.7 going to be released ?
:)
Many many thanks
David
On Mon, 2007-11-19 at 15:27 -0500, Jim Jagielski wrote:
> 2.2.6 has a nasty bug were AJP connections are being closed
> when they shouldn't. 2.2.7 will fix that. In the meantime,
> trying build
2.2.6 has a nasty bug were AJP connections are being closed
when they shouldn't. 2.2.7 will fix that. In the meantime,
trying building httpd with USE_ALTERNATE_IS_CONNECTED defined
as 0 (proxy_util.c).
On Nov 19, 2007, at 9:07 AM, Rainer Jung wrote:
Hi David,
TIME_WAIT is a normal TCP state af
OK I'll give that a go !
Thanks Rainer for your help
D
On Mon, 2007-11-19 at 16:09 +0100, Rainer Jung wrote:
> David Cassidy wrote:
> > Hi Rainer,
> >
> > I've set the ttl to 120
> > re-run the last test with 30 concurrent connections
> >
> > 1 LISTEN
> > 25 CLOSE_WAIT
> > 26
David Cassidy wrote:
Hi Rainer,
I've set the ttl to 120
re-run the last test with 30 concurrent connections
1 LISTEN
25 CLOSE_WAIT
26 FIN_WAIT2
104 ESTABLISHED
924 TIME_WAIT
Not made too much difference. But as the test is only taking 20 secs max
none of the connecti
Hi Rainer,
I've set the ttl to 120
re-run the last test with 30 concurrent connections
1 LISTEN
25 CLOSE_WAIT
26 FIN_WAIT2
104 ESTABLISHED
924 TIME_WAIT
Not made too much difference. But as the test is only taking 20 secs max
none of the connections should have reached
David Cassidy wrote:
Hi !
This is using worker rather than prefork - apache 2.2.6 as comes with
fedora 7. I've changed /usr/sbin/httpd to be /usr/sbin/httpd.worker.
If I make a 1000 requests with ab with keep alive to apache - eg
ab -k -n 1000
then I get alot of connections from apache to tomc
Hi !
This is using worker rather than prefork - apache 2.2.6 as comes with
fedora 7. I've changed /usr/sbin/httpd to be /usr/sbin/httpd.worker.
If I make a 1000 requests with ab with keep alive to apache - eg
ab -k -n 1000
then I get alot of connections from apache to tomcat that are in
TIME_WAI
Hi David,
TIME_WAIT is a normal TCP state after a connection was successfully
closed. Only one side of the connection goes into TIME_WAIT, namely the
side that sent the first FIN.
So since you've got httpd and Tomcat on the same server, you first need
to find out, which side of the conection
Is this worker or prefork MPM?
On Nov 15, 2007, at 4:03 AM, David Cassidy wrote:
Guys,
I'm using mod_proxy in apache 2.2.6 with the ajp connector in tomcat.
apache config
-
BalancerMember ajp://localhost:8009 route=server1 min=0
smax=1000 max=1000 keepalive=On
Guys,
I'm using mod_proxy in apache 2.2.6 with the ajp connector in tomcat.
apache config
-
BalancerMember ajp://localhost:8009 route=server1 min=0
smax=1000 max=1000 keepalive=On
ProxyPass // balancer://myclusterclear/
stickysession=JSESSIONID|jsessionid
Tomc
13 matches
Mail list logo
