Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9D7A817503 for ; Tue, 17 Mar 2015 17:26:55 +0000 (UTC) Received: (qmail 88498 invoked by uid 500); 17 Mar 2015 17:26:55 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 88442 invoked by uid 500); 17 Mar 2015 17:26:55 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 88432 invoked by uid 99); 17 Mar 2015 17:26:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2015 17:26:55 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [65.20.0.212] (HELO rgout0306.bt.lon5.cpcloud.co.uk) (65.20.0.212) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2015 17:26:29 +0000 X-OWM-Source-IP: 209.85.212.173(US) X-OWM-Env-Sender: julianfoad@btinternet.com X-CTCH-RefID: str=0001.0A090204.550863C3.00CF,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-Junkmail-Premium-Raw: score=8/50,refid=2.7.2:2015.3.17.110622:17:8.317,ip=209.85.212.173,rules=__PHISH_SPEAR_HTTP_RECEIVED, __YOUTUBE_RCVD, __MIME_VERSION, __IN_REP_TO, __REFERENCES, __HAS_FROM, __HAS_MSGID, __SANE_MSGID, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __CT, __CT_TEXT_PLAIN, CT_TEXT_PLAIN_UTF8_CAPS, __HELO_GMAIL, __SUBJ_ALPHA_NEGATE, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_ONLY, __RDNS_GMAIL, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __PHISH_SPEAR_STRUCTURE_1, BODY_SIZE_1000_LESS, BODY_SIZE_2000_LESS, __PHISH_SPEAR_STRUCTURE_2, BODY_SIZE_7000_LESS, NO_URI_FOUND, REFERENCES X-CTCH-Spam: Unknown Received: from mail-wi0-f173.google.com (209.85.212.173) by rgout03.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as julianfoad@btopenworld.com) id 550708150023CDAA for dev@subversion.apache.org; Tue, 17 Mar 2015 17:26:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btopenworld.com; s=btcpcloud; t=1426613208; bh=vnvD73pQX5/L054d0if51hRBkLsr9r+vy3PpGuL6H5Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc; b=NQJGlaQAUnVG3aXbK5+fDvylmgqslfamPFLB7Y2lOLeR43bIJRunpkTwfpqEMv027V8U3HUknLN8ffbiDghzJzFGp5mAmijluko9MKfoF1+W7gzOguIPq2iA0LMyucocfw9bercdEEC81xYajvGfJthe4hvQ6Bvwfor5T9bIBG8= Received: by wixw10 with SMTP id w10so17172406wix.0 for ; Tue, 17 Mar 2015 10:26:24 -0700 (PDT) X-Received: by 10.194.59.199 with SMTP id b7mr135992487wjr.26.1426613184650; Tue, 17 Mar 2015 10:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.185.40 with HTTP; Tue, 17 Mar 2015 10:26:04 -0700 (PDT) In-Reply-To: References: <55033BBE.2000905@syntevo.com> <089f01d05f83$2673c460$735b4d20$@qqmail.nl> <5506B7BD.3090406@syntevo.com> <091201d05ff4$7491de40$5db59ac0$@qqmail.nl> <871tkozx5e.fsf@wandisco.com> <002601d0601b$cd44dc50$67ce94f0$@qqmail.nl> <87r3soya5g.fsf@wandisco.com> From: Julian Foad Date: Tue, 17 Mar 2015 17:26:04 +0000 Message-ID: Subject: Re: 1.9.x JavaHL: long initial delay when performing a log To: Philip Martin Cc: Bert Huijben , Marc Strapetz , dev Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org I (Julian Foad) wrote: > To me this algorithm seems better. Oops. My argument for wanting something 'better' than the current trunk implementation (which flushes after 4, 16, 64, 256 log entries) has been blown out of the water. My argument depended on an assumption that the rate of discovery of log entries could be very bursty: for example, the first 2 entries are both recent and are discovered quickly, then a long time before the server discovers the 3rd entry because it is a million revs older. But Stefan has just told me that is not the case: each log entry to be reported takes a broadly similar time, related to the depth of the path and the amount of authz checking, no matter how many million revisions away. Given that news, there is no reason to want anything different from the current implementation. Sorry for the noise. - Julian