Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.219.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMZpi1NsRv5g5+OCoMC7MkOWbSQqaxF8Azv02eM+eOADCrGx3g@mail.gmail.com>
References: 
 <CAMZpi1NsRv5g5+OCoMC7MkOWbSQqaxF8Azv02eM+eOADCrGx3g@mail.gmail.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Wed, 27 Nov 2013 08:37:18 -0500
Message-ID: 
 <CAOFYJNaEqoYJEksGQccHU9M6w7WCUs7Xk6hFbK_n=U78-8KhJA@mail.gmail.com>
Subject: Re: [JCR2.x] JMX and timeseries entries
To: Jackrabbit Users <users@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Nov 27, 2013 at 12:47 AM, J=F6rg Hoh <jhoh228@googlemail.com> wrote=
:
> I have a question to the reasoning behind the timeseries entries availabl=
e
> in Jackrabbit for a number of relevant operational parameters, which are
> suitable to monitor.
>
> Basically I don't see a reason, why you would have time entries instead o=
f
> just a single ever-increasing value. Any monitoring system is capable to
> handle these and calculate the delta between the current value and the la=
st
> one. Even the most simple RRD tool can do that.

We often see cases where a deployment doesn't come with a
pre-configured monitoring system, which makes it difficult or
impossible to investigate past performance of the system. The
TimeSeries mechanism makes it possible to get an overview of the
measured variables since the last restart of a repository for up to
three years, which in many cases is quite useful and would be
impossible to get with a just plain counter.

> I don't see a real good usecase to have timeseries entries and would like
> to have the raw data (as 64bit longs) as I am much more flexible then.

It's still possible for you to sample the value from the array
returned by getValuePerSecond(). Alternatively, if you want to poll at
finer than per-second granularity, you could submit a patch that
exposes the internal counter variable of the TimeSeriesRecorded class.

BR,

Jukka Zitting