AJP Users Out There

[Hugo Slavia]

Thanks Richard!

We will use the default values for retry and timeout.

I will post our settings for the community -- after we have our service
running for few weeks problem free (and without the external file call).

On Wed, Sep 19, 2018 at 12:50 PM Frovarp, Richard <richard.frovarp at ndsu.edu>
wrote:

> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
>
> Default retry is 60. Default timeout is ProxyTimeout.
>
> And yeah, that's what retry does. It cascades errors. It's good for the
> load balancer config, but there are certainly times when it causes a lot
> more harm than good.
>
> On 09/19/2018 02:44 PM, Hugo Slavia wrote:
>
> Thank you Richard and Cameron.
>
> With 'retry = 0'  --- is there a default timeout for a stalled connection?
> Debating whether to go with 'retry =0', and/or timeout.
>
> We had an issue due to a customized plug-in which called an external file
> that was not Java-thread safe (disabled now). The 'retry = 5', started the
> cascading errors.
>
>
> On Tue, Sep 18, 2018 at 8:50 PM Frovarp, Richard <richard.frovarp at ndsu.edu>
> wrote:
>
>> They are very different things. Timeout is to timeout an active
>> connection, or perhaps more accurately a stalled connection.
>>
>> Retry is the number of seconds HTTPD will ignore that backend after an
>> error. I can't remember all what causes it to go into error state. But for
>> that many seconds, it will not proxy and it will return an error back to
>> the requester. So if for some reason you have one request timeout, all
>> other requests to that backend by that worker will fail for retry seconds.
>> So if one of your users times out because Duo is unresponsive, it will fail
>> for all requests for retry seconds. The retry mechanism works well in a
>> load balancing environment, but probably less so if not.
>>
>> We've been bit by this in the past. Can't remember the specifics, and it
>> wasn't against Shib. But now we set retry to 0 as whatever it was that
>> caused it should not effectively cause a denial of service to everything
>> that it did.
>> ------------------------------
>> *From:* users <users-bounces at shibboleth.net> on behalf of Cameron Kerr <
>> cameron.kerr at otago.ac.nz>
>> *Sent:* Tuesday, September 18, 2018 8:23:33 PM
>> *To:* Shib Users
>> *Subject:* RE: AJP Users Out There
>>
>>
>> I would have thought ‘timeout’ would be cleaner…. What are the semantics
>> of ‘retry’ with regard to things like POST and replay detection?
>>
>>
>>
>> That said, I’m from New Zealand, and our instructions (Tuakiri
>> Federation) is based very much on the AAF documentation. I’ve seen no
>> obvious problems from using retry=5 (at least, none that I could account
>> for) in the several years our IdP has run.
>>
>>
>>
>> Hope that helps,
>>
>> Cameron
>>
>>
>>
>> *From:* users <users-bounces at shibboleth.net> *On Behalf Of *Hugo Slavia
>> *Sent:* Wednesday, 19 September 2018 1:16 PM
>> *To:* Shib Users <users at shibboleth.net>
>> *Subject:* AJP Users Out There
>>
>>
>>
>> For the AJP users out there -- with Apache/Tomcat -- do you have a
>> preference between 'retry' or 'timeout' in the AJP configuration?
>>
>>
>>
>> For other services, we generally use the timeout (without retry) -- I saw
>> an example by the Australian Federation with 'retry' -
>> http://wiki.aaf.edu.au/tech-info/idpconf
>>
>>
>>
>>
>>
>> ProxyPass /idp ajp://localhost:8009/idp retry=5
>>
>>
>>
>> ProxyPass /idp ajp://localhost:8009/idp timeout=600
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
>
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180919/59f84015/attachment.html>