On 07/07/2014 07:33 PM, Michal Židek wrote:
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
Btw. I intentionally did not send the patches for 1.11.
I will send them after the patches for master are
accepted.
Thanks,
Michal