From dev-return-38355-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Wed Aug 29 06:56:51 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B67DC180657 for ; Wed, 29 Aug 2018 06:56:50 +0200 (CEST) Received: (qmail 90337 invoked by uid 500); 29 Aug 2018 04:56:49 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 90325 invoked by uid 99); 29 Aug 2018 04:56:49 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2018 04:56:49 +0000 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id D0E91D0F for ; Wed, 29 Aug 2018 04:56:48 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id 130-v6so2561879qkd.10 for ; Tue, 28 Aug 2018 21:56:48 -0700 (PDT) X-Gm-Message-State: APzg51BPPzcwIhwM7FCxfe4hUHqYaOSakkuFBIRhK7RSkkJtZ5xbYy+X Bo1fKRuiiIVsOq+IzSwdRag3vj3tzyoFBJO2H5o1Qg== X-Google-Smtp-Source: ANB0Vdai12NfOpBtbtnfWEN1pqaarhqkwlno8NqLKw3JAhP+Clba4NdI9/Ny5/W1D8XZH5HnKb2xXwmKVAnXnB0MMGk= X-Received: by 2002:a37:c15:: with SMTP id 21-v6mr4701308qkm.95.1535518608342; Tue, 28 Aug 2018 21:56:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Denis Magda Date: Tue, 28 Aug 2018 21:56:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Retries in write-behind store To: dev Content-Type: multipart/alternative; boundary="00000000000032590f05748bc9fb" --00000000000032590f05748bc9fb Content-Type: text/plain; charset="UTF-8" Val, Sounds like a handy configuration option. I would allow setting a number of retries. If the number is set to 0 then a failed update is discarded right away. -- Denis On Tue, Aug 28, 2018 at 9:14 PM Valentin Kulichenko < valentin.kulichenko@gmail.com> wrote: > Folks, > > Is there a way to limit or disable retries of failed updates in the > write-behind store? I can't find one, it looks like if an update fails, it > is moved to the end of the queue and then eventually retried. If it fails > again, process is repeated. > > Such behavior *might* be OK if failures are caused by database being > temporarily unavailable. But what if update fails deterministically, for > example due to a constraint violation? There is absolutely no reason to > retry it, and at the same time it can cause stability and performance > issues when buffer is full with such "broken" updates. > > Does it makes sense to add an option that would allow to limit number of > retries (or even disable them)? > > -Val > --00000000000032590f05748bc9fb--