On 11/21/2014 03:02 PM, Michal Židek wrote:
On 11/21/2014 12:37 PM, Pavel Březina wrote:
> On 11/20/2014 07:22 PM, Michal Židek wrote:
>> Hi,
>>
>> it is probably not very intuitive to choose the
>> 'period' parameter as the initial interval in
>> the backoff feature (ptask). The first_delay and
>> enabled_delay are more suitable for this.
>>
>> See the attached patch.
>>
>> Michal
>
> I still don't think this is the best idea. Let's discuss it a little.
>
> Can you remind me what is the purpose of the backoff feature? Why was it
> implemented? AFAIK it was to detect when we can get back online and the
> randomization was added to spread the load on a server.
We use the ptask API to check if the remote server is still offline. If
it is (offline), the task is rescheduled with doubled period (+random
offest).
>
> I don't like the fact that in the current state the delay parameter is
> ignored if the backoff is set. And therefore all first delay, enabled
> delay and period (with your new patch) is ignored.
Now I am confused a little. With the patch that I attached, the
enabled_delay and first_delay are respected. Only the period
is ignored (note that the enabled/first_delay are passed as the
"delay" paramter to the be_ptask_schedule).
Ah, that is true. Sorry.
We should not ignore the period though. Imagine that you'll use it for
some task where first/enabled delay differs a lot from period. Or where
first/enabled delay will be zero. We should stick to the original plan
and double the period value.
> If I understand the purpose of this backoff feature correctly,
you want
> to increase the period after each execution. But in my opinion you
Yes.
> should still obey the first delay and enabled delay and use the *exact*
> times (even without the random offset IMHO).
We should not ignore the random_offset. That would kill the purpose.
For example if the server goes off for less than first_delay,
the next "online check" will be successful for all clients
(that is why the randomization is needed even in the first delay).
It is why the randomization was added.
OK.
>
> Attached is an *untested* patch to illustrate what I have in mind.
>
>
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel