Improve ScriptHelper.getService(Class)

[Felix Meschberger <fm...@gmail.com>]

Hi,

The ScriptHelper.getService(Class) method of the Scripting Core bundle
implementing the SlingScriptHelper API allows scripts to get access to
OSGi services. This all works perfectly in that the method just forwards
the call through to the framework.

At the end of running the script, the service is then "unget".

Now, the framework will guard access to the service registry and if a
lot of requests are asking for a service while processing the request,
even calling repeatedly for the same service during request processing,
this may result in a contention on the service registry.

I wonder if we could do better with this method by caching the services
not only for the time of processing a component but for longer time,
either during complete request processing or even in a size constrained
cache (of course unregistered services will have to be removed).

WDYT ?

Regards
Felix

Re: Improve ScriptHelper.getService(Class)

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger  wrote
> Hi,
> 
> The ScriptHelper.getService(Class) method of the Scripting Core bundle
> implementing the SlingScriptHelper API allows scripts to get access to
> OSGi services. This all works perfectly in that the method just forwards
> the call through to the framework.
> 
> At the end of running the script, the service is then "unget".
> 
> Now, the framework will guard access to the service registry and if a
> lot of requests are asking for a service while processing the request,
> even calling repeatedly for the same service during request processing,
> this may result in a contention on the service registry.
> 
> I wonder if we could do better with this method by caching the services
> not only for the time of processing a component but for longer time,
> either during complete request processing or even in a size constrained
> cache (of course unregistered services will have to be removed).
> 
> WDYT ?
> 
Some time ago I had similar ideas as with a lot of scripts and parallel
requests this seemed to be a bottleneck - however later tests couldn't
proof that.

Anyway, I think we could do a kind of cache which has non-synced access
(copy on write map). This could be a global cache and by listening to
service events we could simply remove stuff from the cache.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org