[
https://issues.apache.org/jira/browse/OAK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496034#comment-14496034
]
Chetan Mehrotra commented on OAK-2749:
--------------------------------------
{quote}
I forced a new executor so that it would be sure the "slow" part won't
affect the "fast" one. Didn't get how to add a new scheduled job
yet. Do you mind to provide it against my fork (pull request?)? I've
just merged the latest trunk in it.
{quote}
Did not still get it. Executor is backed by a pool. So you simply call
WhiteboardUtils.scheduleWithFixedDelay multiple times with different runnables
and they would not conflict with each other
{quote}
True. Didn't think about it. I think it's more a task that could be
taken care by some groovy script in the oak shell. Otherwise we'll
need some commit hook and in case of changes on the async aspect
will take care of the checkpoints.
{quote}
Or we can simply expose a JMX opertaion to perform this sort of migration
> Provide a "different lane" for slow indexers in async indexing
> --------------------------------------------------------------
>
> Key: OAK-2749
> URL: https://issues.apache.org/jira/browse/OAK-2749
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Davide Giannella
> Assignee: Davide Giannella
> Fix For: 1.3.0
>
> Attachments: OAK-2749-rc1.diff
>
>
> In case of big repositories, asynchronous index like Lucene Property,
> could lag behind as slow indexes, for example Full Text, are taken
> care in the same thread pool.
> Provide a separate thread pool in which such indexes could be
> registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
