You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2010/04/07 17:19:33 UTC

[jira] Commented: (SLING-1478) Improve SlingScriptHelper servie handling

    [ https://issues.apache.org/jira/browse/SLING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854551#action_12854551 ] 

Carsten Ziegeler commented on SLING-1478:
-----------------------------------------

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.

> Improve SlingScriptHelper servie handling
> -----------------------------------------
>
>                 Key: SLING-1478
>                 URL: https://issues.apache.org/jira/browse/SLING-1478
>             Project: Sling
>          Issue Type: Improvement
>          Components: Scripting
>    Affects Versions: Scripting Core 2.0.10
>            Reporter: Carsten Ziegeler
>             Fix For: Scripting Core 2.0.12
>
>
> Felix Meschberger wrote on the Sling dev mailing list:
> 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).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.