[
https://issues.apache.org/jira/browse/OAK-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832535#comment-13832535
]
Michael Dürig commented on OAK-867:
-----------------------------------
Could/should we add some sort of support for thread pools to the whiteboard?
This would be useful for injecting the related scalability concerns into
observation: Currently each observation listener runs in its own dedicated
thread. Giving the deployment control over the thread pool would e.g. make it
possible to use an unbounded pool that starts out with a few threads. Blocking
handlers would then lead to higher resource usage while events are still being
delivered to non blocked listeners. Alternatively a thread pool with a fixed
number of threads could be used to limit CPU allocated to event processing. In
the extreme this could even be a single thread such that all observation
listeners share this same thread.
See also http://markmail.org/message/u36wms6q2tglfs4z
> Oak whiteboard
> --------------
>
> Key: OAK-867
> URL: https://issues.apache.org/jira/browse/OAK-867
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, jcr
> Reporter: Jukka Zitting
> Fix For: 0.14
>
>
> Instead of injecting generic components like {{ScheduledExecutorService}},
> {{MBeanServer}}, etc. to all places where they are needed (and thus having
> complex dependency chains), I'd like to introduce a whiteboard concept that
> allows all Oak components to publish information that can then be acted on by
> other components. The implementation should be directly implementable in OSGi
> environments with OSGi services, but also simple enough to work in
> traditional non-OSGi deployments.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
