I've been testing the 1.2.17 (soon to be 1.2.18) release and have
noticed a problem in worker recovery.
If I restart a Tomcat instance and mod_jk notices that it went down,
mod_jk waits 60 seconds recovery time before it tries again (see
jk_lb_worker.h WAIT_BEFORE_RECOVER and struct jk_shm_worker
Is the 60 seconds hard-coded?
I'd hope not...
Once you have some interesting web apps in Tomcat it often takes a bit
longer than 10 seconds -- and on my laptop just took a full 60 seconds,
but that is rather unusual (a restart thereafter only took 18).
David Rees wrote:
I've been testing th
On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
Is the 60 seconds hard-coded?
I'd hope not...
Once you have some interesting web apps in Tomcat it often takes a bit
longer than 10 seconds -- and on my laptop just took a full 60 seconds,
but that is rather unusual (a restart thereafter only to
Well a new show stopper for 1.2.18 ;(
2006/7/18, David Rees <[EMAIL PROTECTED]>:
On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds hard-coded?
>
> I'd hope not...
>
> Once you have some interesting web apps in Tomcat it often takes a bit
> longer than 10 seconds -- and on my
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why it would be?
JK 1.2.18 is still not tagged.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way of
avoiding errors is meant to be retries, the second way is failover. Only
then comes recovery.
3) A worker that goes into error stat
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Regards,
Mladen.
---
Rainer Jung wrote:
6) We could make the interval configurable, but there is a real danger
of users thinking, that a low recovery interval, like 10 seconds would
make things better, whereas it is very likely, that it would make there
whole system kind of oscillate.
Well, I don't wish to li
Mladen Turk wrote:
Rainer Jung wrote:
6) We could make the interval configurable, but there is a real danger
of users thinking, that a low recovery interval, like 10 seconds would
make things better, whereas it is very likely, that it would make
there whole system kind of oscillate.
Wel
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Right, and the reason it was never changed was because
no one gave any reason to change it.
Like said, 60 seconds recover timeout was probably used
since someone thought it should be 'fi
Rainer Jung wrote:
Mladen Turk wrote:
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...
Increasing is something totally different. I just want to avoid people
ending with a system that changes error/ok states with a high frequency,
so that the whole syste
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently between states. At lea
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why ? With the current implementation, low values will have extremely
bad behavior in some cases. You should actually configure long
intervals, without retries.
Rémy
---
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way of
avoiding errors is meant to be retries, the second way is failover. Only
then comes recovery.
3) A worker that
Rainer Jung wrote:
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently be
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
2) The recover feature is used in the load balancer and the first way
of avoiding errors is meant to be retries, the second way is failover.
Only then comes recovery.
3) A worker that
The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.
FW who eat the FIN-CLOSE ?
--
Henri Gomez wrote:
The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.
FW who eat the FIN-CLOSE ?
Yes, if not
I'd say that it's a feature enhancement, not a show stopper.
And not a regression nor a bug :)
On Jul 19, 2006, at 5:16 AM, Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
2006/7/18, David Rees <[EMAIL PROTECTED]>:
On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds
ok :)
2006/7/19, Jim Jagielski <[EMAIL PROTECTED]>:
I'd say that it's a feature enhancement, not a show stopper.
And not a regression nor a bug :)
On Jul 19, 2006, at 5:16 AM, Henri Gomez wrote:
> Well a new show stopper for 1.2.18 ;(
>
> 2006/7/18, David Rees <[EMAIL PROTECTED]>:
>> On 7/18/0
On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Thanks that should work around my issue quite ni
On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
used to recover nearl
David Rees wrote:
On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
On 7/19/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote:
> But when all your workers are down, what is the harm in trying to
> recover more quicky?
Because the TC on the other side is probably busy and you may cause a
huge increase of threads (X2)... And that will not help for the recovery.
On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
While the change you made allows you to configure
David Rees wrote:
While the change you made allows you to configure the worker to a
recover_time lower than 60 seconds, it doesn't let you change it to a
value lower than 60 using the status worker.
Still investigating, but it looks like there are a number of other
places it should be changed.
David Rees wrote:
Thanks that should work around my issue quite nicely. I'll check out
SVN and give a whirl (unless a new tag is to be rolled again shortly?)
Try 1.2.18.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition
On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
David Rees wrote:
> Thanks that should work around my issue quite nicely. I'll check out
> SVN and give a whirl (unless a new tag is to be rolled again shortly?)
Try 1.2.18.
1.2.18 works much better, thanks!
-Dave
---
On 7/24/06, David Rees <[EMAIL PROTECTED]> wrote:
On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
> David Rees wrote:
> > Thanks that should work around my issue quite nicely. I'll check out
> > SVN and give a whirl (unless a new tag is to be rolled again shortly?)
>
> Try 1.2.18.
1.2.18 work
On 7/25/06, David Rees <[EMAIL PROTECTED]> wrote:
On 7/24/06, David Rees <[EMAIL PROTECTED]> wrote:
> On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
> > David Rees wrote:
> > > Thanks that should work around my issue quite nicely. I'll check out
> > > SVN and give a whirl (unless a new tag is
Hi David,
David Rees schrieb:
> On 7/25/06, David Rees <[EMAIL PROTECTED]> wrote:
>> On 7/24/06, David Rees <[EMAIL PROTECTED]> wrote:
>> I spoke too soon. I've been testing 1.2.18 further, and recover time
>> while appearing to change, I can not get mod_jk to actually recover
>> any faster than 6
On 7/26/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
At least concerning thi spoint we devs had no confusion. The docs under
dist have been updated when 1.2.18 has been put on dev:
http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/config/workers.html
Yes, it appears that I am the one co
32 matches
Mail list logo
