Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3F6B99E6C for ; Thu, 16 Feb 2012 14:16:07 +0000 (UTC) Received: (qmail 80586 invoked by uid 500); 16 Feb 2012 14:16:07 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 80552 invoked by uid 500); 16 Feb 2012 14:16:06 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 80545 invoked by uid 99); 16 Feb 2012 14:16:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2012 14:16:06 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of alex.parvulescu@gmail.com designates 209.85.216.49 as permitted sender) Received: from [209.85.216.49] (HELO mail-qw0-f49.google.com) (209.85.216.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2012 14:15:59 +0000 Received: by qadc14 with SMTP id c14so3576466qad.1 for ; Thu, 16 Feb 2012 06:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zZdiuyhEwrQI5W+qQiVeDcCc1WKtr7cdfdxtE2Lh6tc=; b=hB0Atz8l9raOVY/Vb8Ukojnf98vIYP/jJOIMfu/cY6RPf4w+ZWSTxcSgy1Nie+1flx MCSp/pJMt3fys31xN1HIhmM+z9BGrQ3IVjL7ZrIZ+ctG7zmKhravgqZl105BZbr8bzwT P1lJ5MXbfWpfaypUWaNmZpVHBs2JvpF7CiduY= MIME-Version: 1.0 Received: by 10.229.76.9 with SMTP id a9mr1899423qck.76.1329401738020; Thu, 16 Feb 2012 06:15:38 -0800 (PST) Received: by 10.229.96.15 with HTTP; Thu, 16 Feb 2012 06:15:37 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Feb 2012 15:15:37 +0100 Message-ID: Subject: Re: RepositoryStatistics question From: Alex Parvulescu To: dev@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=002354470dcc5bc89404b91576b9 X-Virus-Checked: Checked by ClamAV on apache.org --002354470dcc5bc89404b91576b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mete, The answer depends on the implementation, and as you can see on the wiki page [0] these two counters have not been implemented yet :) You have 2 options here: 1) is what you listed above: you provide an incremental implementation where each time there is a change to the number of bundles, you push that info to the counter via the #addAndGet(long delta) method. In this case, yes we should change to non-incremental. or 2) similar to BUNDLE_CACHE_SIZE_COUNTER you provide the absolute number each time via #set(long newValue), possibly at a lower frequency that the one at the actual updates come in. So, as I've said it depends on the actual implementation and not having one yet means that if you find it easier the other way around (#1) we can switch without breaking anything. best, alex [0] http://wiki.apache.org/jackrabbit/Statistics On Thu, Feb 16, 2012 at 2:20 PM, Mete Atamel wrote: > Hi, > > I was looking at some of the values of Type enum in RepositoryStatistics > class and these two caught my attention: > > BUNDLE_COUNTER(true), > > BUNDLE_WS_SIZE_COUNTER(true), > > I'm assuming BUNDLE_COUNTER is the current number of nodes/bundles and > BUNDLE_WS_SIZE_COUNTER is the total size of all nodes/bundles in the > workspace (correct me if I'm wrong). The problem is that these enums are > initialized with true, meaning they will reset their counts to zero every > second and this is kind of weird. > > For example, if 100 nodes are created at time 1 and time 3, you'd see > something like this for BUNDLE_COUNTER: 100, 0, 100, 0, 0, ... But I'd > expect to see 100, 100, 200, 200, 200, =85 Because BUNDLE_COUNT sounds li= ke > the total number of nodes at the current time rather than new bundles > created at the current time. If it were named NEW_BUNDLE_COUNT, I'd expec= t > to see 100, 0, 100, 0, 0, =85Same goes for BUNDLE_WS_SIZE_COUNTER. > > So, I'm suggesting that we change these enum values to initialize with > false instead and I'm curious to know what everyone else thinks. > > Thanks, > Mete > --002354470dcc5bc89404b91576b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mete,

The answer depends on the implementation, and a= s you can see on the wiki page [0] these two counters have not been impleme= nted yet :)

You have 2 options here:=A0

1) is what you listed above: you provide an incremental impl= ementation where each time there is a change to the number of bundles, you = push that info to the counter via the #addAndGet(long delta) method.
In this case, yes we should change to non-incremental.

<= /div>
or

2) similar to=A0BUNDLE_CACHE_SIZE_COU= NTER you provide the absolute number each time via #set(long newValue), pos= sibly at a lower frequency that the one at the actual updates come in.

So, as I've said it depends on the actual implement= ation and not having one yet means that if you find it easier the other way= around (#1) we can switch without breaking anything.


best,
alex



On Thu, Feb 16, 2012 at 2:20 PM, Mete Atamel <matamel@adobe.com> wrote:
Hi,

I was looking at some of the value= s of Type enum in RepositoryStatistics class and these two caught my attent= ion:

=A0 =A0 =A0 =A0=A0BUNDLE= _COUNTER(true),

=A0 =A0 =A0 =A0 BUNDLE_WS_SIZE_COUNTER(true),


I'm assuming BUNDLE_COUNTE= R is the current number of nodes/bundles and BUNDLE_WS_SIZE_COUNTER is the = total size of all nodes/bundles in the workspace (correct me if I'm wro= ng). The problem is that these enums are initialized with true, meaning the= y will reset their counts to zero every second and this is kind of weird.= =A0

For example, if 100 nodes are create= d at time 1 and time 3, you'd see something like this for BUNDLE_COUNTE= R: 100, 0, 100, 0, 0, ... But I'd expect to see 100, 100, 200, 200, 200= , =85 Because BUNDLE_COUNT sounds like the total number of nodes at the cur= rent time rather than new=A0bundles= created at the current time. If it were named=A0NEW_BUNDLE_COUNT, I'd = expect to see 100, 0, 100, 0, 0, =85Same goes for=A0BUNDLE_WS_SIZE_C= OUNTER.=A0

So, I'm suggesting that we chang= e these enum values to initialize with false instead and I'm curious to= know what everyone else thinks.

Thanks,
Mete

--002354470dcc5bc89404b91576b9--