On 11/21/2014 12:37 PM, Pavel Březina wrote:
On 11/20/2014 07:22 PM, Michal Židek wrote:
> 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.
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
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).
If I understand the purpose of this backoff feature correctly, you want
to increase the period after each execution. But in my opinion you
should still obey the first delay and enabled delay and use the
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.
Attached is an *untested* patch to illustrate what I have in mind.