[Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili <to...@gmail.com>]

Hi all,

since a few days I'm trying to capture some simple stats on the Oak
query engine and I'm struggling with instrumenting the
StatisticsProvider which is used to update MeterStats and the likes.

While everything has gone smoothly on the indexing side as obtaining a
StatisticsProvider was as simple as attaching a @Reference to obtain
the StatisticsProvider OSGi service in LuceneIndexProviderService,
this seems hardly possible on the query side.
In fact QueryEngineImpl and its "companions" classes in
org.apache.jackrabbit.oak.query package (from oak-core) do not use
OSGi at all and this seems to make it very hard to obtain a
StatisticsProvider instance.

After having dig into the code for a while I can see following options:
- have a dedicated OSGi service on the query side that can be then
polled in a static way from QueryEngineImpl in order to obtain such a
reference (see patch from OAK-7904 [1])
- pass the StatisticsProvider instances down the whole stack from Oak
class (or from MutableRoot/ImmubtableRoot)

I personally don't like any of the above so I was seeking for some
alternative solution which wouldn't screw up design / encapsulation
and all programming best practice that much.
Is there a way to obtain the StatisticProvider reference from a non
OSGi context which wouldn't involve pushing a Whiteboard object down
from Oak to QueryEngineImpl ?

Regards,
Tommaso

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili <to...@gmail.com>]

thanks Francesco and Robert for your replies.
I think what the query engine is missing to behave like the segment
node store is that one OSGi service which gets picked up with all
those required wirings, so that we can pass it down the stack.
However it sounds like the latter option is more work but in the end
(hopefully) better in terms of code quality / testability / etc.

Regards,
Tommaso
Il giorno mer 28 nov 2018 alle ore 11:43 Robert Munteanu
<ro...@apache.org> ha scritto:
>
> On Wed, 2018-11-28 at 11:34 +0100, Francesco Mari wrote:
> > On Tue, 27 Nov 2018 at 11:45, Tommaso Teofili <
> > tommaso.teofili@gmail.com>
> > wrote:
> >
> > > After having dig into the code for a while I can see following
> > options:
> > > - have a dedicated OSGi service on the query side that can be then
> > > polled in a static way from QueryEngineImpl in order to obtain such
> > a
> > > reference (see patch from OAK-7904 [1])
> > >
> >
> > I suggest you don't pursue this option. I find that every service
> > introduces additional complexity and hinders the testability of the
> > code.
> > In oak-segment-tar we pushed all the OSGi bits to a couple of
> > services
> > (read below) and everything else is just plain Java code that
> > explicitly
> > declares its dependencies. The API is clearer and the code is much
> > more
> > testable. You don't want to resort on oak-it-osgi to test your stuff
> > ;)
>
> Note that with OSGi R7 you can use constructor injection, and that
> makes it really easy to construct your object graphs manually for
> testing. So no need to resort to ITs for testing OSGi-aware components.
>
> Not really arguing for one option or the other, but wanted to make sure
> everyone is aware of the most recent changes.
>
> Thanks,
>
> Robert
>

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Robert Munteanu <ro...@apache.org>]

On Wed, 2018-11-28 at 11:34 +0100, Francesco Mari wrote:
> On Tue, 27 Nov 2018 at 11:45, Tommaso Teofili <
> tommaso.teofili@gmail.com>
> wrote:
> 
> > After having dig into the code for a while I can see following
> options:
> > - have a dedicated OSGi service on the query side that can be then
> > polled in a static way from QueryEngineImpl in order to obtain such
> a
> > reference (see patch from OAK-7904 [1])
> >
> 
> I suggest you don't pursue this option. I find that every service
> introduces additional complexity and hinders the testability of the
> code.
> In oak-segment-tar we pushed all the OSGi bits to a couple of
> services
> (read below) and everything else is just plain Java code that
> explicitly
> declares its dependencies. The API is clearer and the code is much
> more
> testable. You don't want to resort on oak-it-osgi to test your stuff
> ;)

Note that with OSGi R7 you can use constructor injection, and that
makes it really easy to construct your object graphs manually for
testing. So no need to resort to ITs for testing OSGi-aware components.

Not really arguing for one option or the other, but wanted to make sure
everyone is aware of the most recent changes.

Thanks,

Robert

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Francesco Mari <ma...@gmail.com>]

On Tue, 27 Nov 2018 at 11:45, Tommaso Teofili <to...@gmail.com>
wrote:

> After having dig into the code for a while I can see following options:
> - have a dedicated OSGi service on the query side that can be then
> polled in a static way from QueryEngineImpl in order to obtain such a
> reference (see patch from OAK-7904 [1])
>

I suggest you don't pursue this option. I find that every service
introduces additional complexity and hinders the testability of the code.
In oak-segment-tar we pushed all the OSGi bits to a couple of services
(read below) and everything else is just plain Java code that explicitly
declares its dependencies. The API is clearer and the code is much more
testable. You don't want to resort on oak-it-osgi to test your stuff ;)


> - pass the StatisticsProvider instances down the whole stack from Oak
> class (or from MutableRoot/ImmubtableRoot)
>

In oak-segment-tar we opted for this option. We have two OSGi services that
represent the entry point for the oak-segment-tar bundle,
SegmentNodeStoreService and SegmentNodeStoreFactory. Both the services have
a reference to a StatisticsProvider, which is passed down the stack to the
bowels of the bundle.

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili <to...@gmail.com>]

p.s.:

[1] : https://issues.apache.org/jira/browse/OAK-7904?focusedCommentId=16697298&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16697298
Il giorno mar 27 nov 2018 alle ore 11:38 Tommaso Teofili
<to...@gmail.com> ha scritto:
>
> Hi all,
>
> since a few days I'm trying to capture some simple stats on the Oak
> query engine and I'm struggling with instrumenting the
> StatisticsProvider which is used to update MeterStats and the likes.
>
> While everything has gone smoothly on the indexing side as obtaining a
> StatisticsProvider was as simple as attaching a @Reference to obtain
> the StatisticsProvider OSGi service in LuceneIndexProviderService,
> this seems hardly possible on the query side.
> In fact QueryEngineImpl and its "companions" classes in
> org.apache.jackrabbit.oak.query package (from oak-core) do not use
> OSGi at all and this seems to make it very hard to obtain a
> StatisticsProvider instance.
>
> After having dig into the code for a while I can see following options:
> - have a dedicated OSGi service on the query side that can be then
> polled in a static way from QueryEngineImpl in order to obtain such a
> reference (see patch from OAK-7904 [1])
> - pass the StatisticsProvider instances down the whole stack from Oak
> class (or from MutableRoot/ImmubtableRoot)
>
> I personally don't like any of the above so I was seeking for some
> alternative solution which wouldn't screw up design / encapsulation
> and all programming best practice that much.
> Is there a way to obtain the StatisticProvider reference from a non
> OSGi context which wouldn't involve pushing a Whiteboard object down
> from Oak to QueryEngineImpl ?
>
> Regards,
> Tommaso