From dev-return-97956-archive-asf-public=cust-asf.ponee.io@sling.apache.org Tue Jun 25 15:41:07 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 05A0318062F for ; Tue, 25 Jun 2019 17:41:06 +0200 (CEST) Received: (qmail 73452 invoked by uid 500); 25 Jun 2019 15:41:01 -0000 Mailing-List: contact dev-help@sling.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@sling.apache.org Delivered-To: mailing list dev@sling.apache.org Received: (qmail 73439 invoked by uid 99); 25 Jun 2019 15:41:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Jun 2019 15:41:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CD9FDE2E1D for ; Tue, 25 Jun 2019 15:41:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4C36325817 for ; Tue, 25 Jun 2019 15:41:00 +0000 (UTC) Date: Tue, 25 Jun 2019 15:41:00 +0000 (UTC) From: "Timothee Maret (JIRA)" To: dev@sling.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (SLING-8531) Support JournalAvailabilityChecker exponential backoff MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SLING-8531?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated SLING-8531: ---------------------------------- Reporter: Timothee Maret (was: Christian Schneider) > Support JournalAvailabilityChecker exponential backoff=20 > ------------------------------------------------------- > > Key: SLING-8531 > URL: https://issues.apache.org/jira/browse/SLING-8531 > Project: Sling > Issue Type: Improvement > Components: Content Distribution > Affects Versions: Content Distribution Journal Core 0.1.2 > Reporter: Timothee Maret > Assignee: Timothee Maret > Priority: Major > Fix For: Content Distribution Journal Core 0.1.4 > > > The average load generated by=C2=A0JournalAvailabilityChecker multiplies = quickly for multi tenant deployments. The checker can be configured (via Sl= ing Scheduler {{scheduler.period}}) to reduce the polling frequency but doi= ng so also reduces the sensibility=C2=A0to detect availability changes. > To improve the sensibility we should support an exponential backoff algor= ithm. The algorithm would=C2=A0divide the rate by two (up to a limit) every= time the availability status=C2=A0does not change and reset=C2=A0the rate= =C2=A0when the status changes.=C2=A0Steady states (available or unavailable= )=C2=A0would eventually yield=C2=A0the least=C2=A0load. In the average case= (availability status is steady) the load will be reduced up to the limit.= =C2=A0In the worst case (availability changes all the time) the load will n= ot be reduced compared to today.=C2=A0 > The base rate would be=C2=A0Sling Scheduler=C2=A0{{scheduler.period}}. Th= e rate at time t + 1 would be computed as follow:=C2=A0Rate~t+1~ =3D=C2=A0M= ultiplier~t+1~=C2=A0* Rate~t+1~. The table below summarise how the multipli= er would=C2=A0evolve according to the available status change.=C2=A0 > ||State~t~||State~t+1~||Multiplier~t+1~|| > |unavailable|unavailable|max(2 * Multiplier~t~, limit)| > |unavailable|available|1| > |available|unavailable|1| > |available|available|max(2 * Multiplier~t~, limit)| > The limit would be hardcoded to 16 which would reduce the load by an orde= r of magnitude, we could expose=C2=A0the limit as a configuration later if = needed. > There should be no need to randomise the multiplier for now as the checke= r are=C2=A0expected to be started at random time.=C2=A0If we hit a scenario= where the checkers start at the same time, we could simply randomise the f= irst scheduled event. > =C2=A0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)