[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] wserver_timeout value causing cascading failure?
From: |
Kim Minh Kaplan |
Subject: |
Re: [Sks-devel] wserver_timeout value causing cascading failure? |
Date: |
Wed, 26 Apr 2017 08:41:25 +0000 |
Jonathon Weiss wrote:
> 1) multiple client connections come in and are passed from Apache to
> SKS (possibly while SKS is working on a previous query).
>
> 2) SKS works on the first query and returns the answer
>
> 3) for some reason the owner of the second query has disappeared (I
> assume this is because the client gives up, and maybe hist reload or
> something, and Apache notices that the client is gone and drops all
> connection state)
>
> 4) SKS waits 'wserver_timeout' (default 60) seconds, and gives up and
> goes on to the next connection.
>
> 5) The next client gave up during the timeout, and the problem expands
> out of control.
[…]
> This all leaves me with several questions:
>
> 1) Does anyone see any flaws in my analysis? or work-around?
There is something strange happening in items 3 or 4. If Apache
somehow « drops all connection state » it should close its connection
to SKS, no? And SKS should then instantly see the closed connection
instead of timing out.
> 3) Any suggestions on what to do if/when wserver_timeout=1 becomes
> insufficient?
In addition to what Phil Pennock suggested you might want to try with
very large ProxyIOBufferSize
(http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyiobuffersize)
and maybe also ProxyReceiveBufferSize
(http://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#proxyreceivebuffersize).
I read that this last one may require OS dependent tweekings.
> 4) Any chance of detecting this sort of problem in sksd and skipping
> the timeout altogether?
If it is what you describe in 3 & 4 it would be worthwhile to
investigate why SKS does not immediatly see that the connection was
closed.
--
Kim Minh.