https://issues.apache.org/bugzilla/show_bug.cgi?id=57520

--- Comment #10 from Yann Ylavic <[email protected]> ---
(In reply to dk from comment #9)
> Based on your insistence that the problem must be on Jetty side I did
> in-depth investigation.

Sorry if it appeared insistent, it was not my intent.

My goal was more about giving an overview on the issues regarding connections
between a proxy and a backend (I may have been confusing in that goal though,
based on a real use case), because these questions keep coming regularly either
on bugzilla or mailing lists (or personnal experience).

I think this is is racy by nature, under heavy stress no one should expect zero
error.
And jetty's graceful shutdown is not an exception (IMHO), it has to decide when
to stop listenning/accepting clients, but the proxy has no idea about this and
still asks for connections (especially with retry=0)...

> 
> Just for the record this final test was completed under the following
> settings in the VirtualHost:
> 
>     SetEnv force-proxy-request-1.0 1
>     SetEnv proxy-nokeepalive 1
>     SetEnv proxy-initial-not-pooled 1

Those 3 are redundant, you could leave the second only.
Beside redundancy, I'd suggest not using force-proxy-request-1.0, unless the
backend really expects HTTP/1.0, or requests with chunked encoding is not
supported on jetty.
It will cause chunked requests' bodies to be spooled on the disk before being
forwarded (as Content-Length).

> 
>     RequestHeader unset Expect early
> 
> ... and this balancer setup:
> 
> <Proxy balancer://mybalancer>
>     ProxySet failonstatus=502,503 maxattempts=1000
>     BalancerMember http://host1:9999 timeout=3600 retry=0 ping=30
> disablereuse=on keepalive=on
>     BalancerMember http://host2:9999 timeout=3600 retry=0 ping=30
> disablereuse=on keepalive=on
>     BalancerMember http://host3:9999 timeout=3600 retry=0 ping=30
> disablereuse=on keepalive=on
> </Proxy>

disablereuse is also redundant with SetEnvs above.
ping is ajp:// specific in 2.2.x, it is implemented in 2.4.x for http://, so
you can leave it as is from a migration perspective...
But if the goal is to let jetty handle the Expect header (with RequestHeader
unset above), it won't work in 2.2.x, and since httpd won't handle it either
(still per RequestHeader rule), no one will statisfy the client's
expectation...

> 
> I intend to leave these settings "as is" for our production system, unless
> there is a good reason (and low risk) to restore keep alives or if you might
> advise change any other changes... I suppose if all requests have large
> payloads, the keepalives won't be adding much benefit?

Probably, especially if it works "as is"...
I'd personnaly run an heavier stress test and try to get things race ( but
that's *my* theory ;) and then if it happens, try the other way...

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to