JK connection_keepalive configuration

[Rainer Jung <ra...@kippdata.de>]

Hi Mladen,

any thoughts, how we could make configuring connection_keepalive better?

We implicitely use prepost_timeout, so there's no way to use the
occasional keepalive CPING probing without adding CPINGs to any request.

I think in most cases, the actual timeout used for the CPONG response in
the three cases connection check, pre request check and keepalive check
do not matter that much, they usually can be set to the same value.

So we could introduce a more general probe_timeout and a flag use_probes
indicating, which types of probes are wanted (connect, request, idle).

The probe_timeout will be copied to prepost_timeout resp.
connect_timeout depending on the flag value and prepost_timeout and
connect_timeout will get deprecated (but still used if not overwritten
by the new directives).

The flag could be a bitmap, but I would prefer we make it a list
attribute with string arguments ("connect", "request", "idle").

By this we would offer the alternative

   probe_timeout, use_probes, connection_keepalive

to

   prepost_timeout, connect_timeout, connection_keepalive

We would loose the ability to set the CPONG timeouts individually, but
we gain the ability to use keepalive CPINGs without prepost CPINGs.

Of course by introducing even more attributes we can keep the individual
CPING timeouts, but I don't really see a reason. I want to get the
attributes right, before we release this nice feature.

Comments?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: JK connection_keepalive configuration

[Rainer Jung <ra...@kippdata.de>]

Mladen Turk schrieb:
> Rainer Jung wrote:
>> Hi Mladen,
>>
>> any thoughts, how we could make configuring connection_keepalive better?
>>
>> Of course by introducing even more attributes we can keep the individual
>> CPING timeouts, but I don't really see a reason. I want to get the
>> attributes right, before we release this nice feature.
>>
>> Comments?
>>
> 
> We must not change the existing behavior nor directives.
> They are widely used, so IMO, we can only use the
> additional directive (probe_timeout is fine),
> although ping_timeout is more intuitive.

I didn't want to change the behaviour. But if we want to make people
aware of the new (and better) attributes, we can always add attributes
to the deprecated_properties in jk_util.c. The only thing this does, is
logging a warning during startup. As long as we keep the code handling
the attributes (and of course we will keep it during 1.2.x), the
functionality wil still be there.

> We can then use that ping_timeout for connect_timeout
> if the connect_timeout value is boolean (allowing booleans first)
> The same for prepost_timeout.

That works.

> so.
> worker.x.ping_timeout=NNN
> worker.x.connect_timeout=True|On|1 (will set to ping_timeout)
> worker.x.prepost_timeout=True|On|1 (will set to ping_timeout)
> 
> If you like we could use one additional
> worker.x.ping_mode=connect,prepost,keepalive
> I'd like we use single letters here 'CPK'

I like this much better. Letters are fine, I would allow short form
(letters) and long form (easier to understand in the configuration
file), like we do for activation. We could also add "a=all" meaning
whatever cping probes are there now and in the future.

I would suggest we use a non zero default value for ping_timeout, like
e.g. 10 seconds. That way most people only need to activate the type of
timeout wanted via ping_mode and need not care about the timeout value
itself. Code for setting internally prepost and connect timeouts gets
1-2 lines longer, because we can't simply take ping_timeout as the
default, but the user experience will be better (e.g. if the set
ping_mode to use pings, but don't give any timeouts?).

People only using the old attributes prepost_timeout and connect_timeout
will not experience any differing behaviour.

> Also I don't like we deprecate *_timeout directives.

Even if it only means "log a warning"?

> Next,
> connection_keepalive should probably get
> renamed to connection_keepalive_interval

... or maybe we get rid of "keepalive", because there is already so much
confusion between TCP and HTTP keepalive (and now also AJP). What about
connection_ping_interval or connection_test_interval?

I saw you already started with some changes, I can add some of the rest
tomorrow evening.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: JK connection_keepalive configuration

[Mladen Turk <mt...@apache.org>]

Rainer Jung wrote:
> Hi Mladen,
> 
> any thoughts, how we could make configuring connection_keepalive better?
> 
> Of course by introducing even more attributes we can keep the individual
> CPING timeouts, but I don't really see a reason. I want to get the
> attributes right, before we release this nice feature.
> 
> Comments?
>

We must not change the existing behavior nor directives.
They are widely used, so IMO, we can only use the
additional directive (probe_timeout is fine),
although ping_timeout is more intuitive.

We can then use that ping_timeout for connect_timeout
if the connect_timeout value is boolean (allowing booleans first)
The same for prepost_timeout.

so.
worker.x.ping_timeout=NNN
worker.x.connect_timeout=True|On|1 (will set to ping_timeout)
worker.x.prepost_timeout=True|On|1 (will set to ping_timeout)

If you like we could use one additional
worker.x.ping_mode=connect,prepost,keepalive
I'd like we use single letters here 'CPK'

Also I don't like we deprecate *_timeout directives.

Next,
connection_keepalive should probably get
renamed to connection_keepalive_interval


Cheers
-- 
^(TM)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org