On 07/07/2014 03:09 PM, Michal Židek wrote:
On 07/07/2014 03:01 PM, Jakub Hrozek wrote:
> On Mon, Jul 07, 2014 at 02:11:52PM +0200, Michal Židek wrote:
>> On 07/06/2014 06:44 PM, Simo Sorce wrote:
>>> On Sun, 2014-07-06 at 12:42 -0400, Simo Sorce wrote:
>>>> On Fri, 2014-07-04 at 12:34 +0200, Michal Židek wrote:
>>>>> Hi Sumit,
>>>>>
>>>>> actually your suggestion was one of my first ideas, but
>>>>> It looked like strange behaviour to me if the first
>>>>> getent (or any request for data not present int the
>>>>> cache) after offline_timeout period returned nothing
>>>>> even if the server was already available and the second
>>>>> (1 or 2 seconds after the first) returned proper data. I
>>>>> thought this may be considered a bug for some people (even
>>>>> if it is not a major regression :) ). The patch I sent
>>>>> was then an improvement over this initial idea (from my POV).
>>>>>
>>>>> I understand your suggestion and concern, but I would
>>>>> prefer to stick with the approach in the patch I sent.
>>>>
>>>> Can we at least use a backoff scheme where we increase timeout periods
>>>> every time we try and find ourselves offline ?
>>>>
>>>> Try 1 minute, then 2, then 4, then 8, 16, 32, 64, 128 ...
>>
>> Good idea, but this might result in SSSD being too long
>> offline for no good reason. Would it make sense
>> to introduce a new config option for upper bound of
>> this delay (like offline_timeout_max)? Without this option
>> it would be difficult for me to accept this change. But
>> I wonder what the default value should be... maybe 64?
>
> I would actually prefer to have a sane default..one hour with some
> randomization to avoid "8AM flood" maybe.
>
>>
>>>
>>> It would also probably be a good idea to randomize a little the delay,
>>> otherwise we risk thundering herd situations.
>>>
>>> Simo.
>>>
>>
>> Should the maximal value of the random offset be configurable?
>
> I would prefer to have neither the random offset nor the maximum cap
> configurable, or have a undocumented option unless we know it makes
> sense to let the admin configure the option.
>
> I'm afraid we have too many timeout options already and it's difficult
> for admins to know them even without adding onother one..
>
That is true. I will hardcode the values then.
>> Or is it not needed (I personally think it is not, but would like
>> to hear other opinions as well)? I am also not sure what the
>> default value should be (I was thinking 30 seconds).
>>
>> Will send new patches soon, thanks for suggestions.
>>
>> Michal
>
Here are the new patches. The hardcoded values are
30 seconds for the maximum random offset
3600 seconds for the maximum backoff delay
Michal