Hi, I don't have a clear proposal for the entire problem, but let me add a few thoughts to the info you provided. It looks like there are 2 problems we need to fix: first one is indexer being picked up by two threads (sync and async), second one is indexer needs to know if it is running in a sync or an async run.
For the first issue, I'd like to turn it around a bit and say that we don't need to introduce a new type, we can extend the current index definition for the 'async' property and allow multiple values. In the current setup we either have 'null' (missing property) which is mapped to the sync indexing job, or 'async=async' for a background thread, so after this change we'd have 'async=['', 'async'], which means that this specific indexer would be picked up by the sync indexer job and also by the 'async' job. this also lets us map to any of the indexing lanes we have configured easily. Second issue: how to know if it's a sync or async job? Changing ' IndexEditorProvider' is the obvious solution, but the amount of changes needed might be too much, so I'd like to explore another option as well. What about overloading the 'IndexUpdateCallback' with a 'isSync()' method coming from the 'IndexUpdate' component. This will reduce the change footprint and only components that need to know this information will use it. best, alex On Wed, Aug 3, 2016 at 7:43 AM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > Hi Team, > > Currently one can set "async" flag on an index definition to indicate > wether given index should be effective for synchronous commit or to be > used for async indexing. For Hybrid Lucene indexing case [1] I need to > have a way where same index definition gets used in both. > > So if a index definition at /oak:index/fooLuceneIndex is marked as > "hybrid" [2] then we need have LuceneIndexEditorProvider invoked for > both > > 1. Commit Time - Here the editor would just create Document and not add to > index > 2. Async indexing time - Here the current implemented approach of > indexing would happen > > And in doing that the LuceneIndexEditorProvider needs to be informed > in which mode it is being invoked. So to support that we need some > enhancement in IndexUpdate logic where by same index definition is > used in both mode and editor knows the indexing mode. > > Probably this would require a new interface for IndexEditorProvider. > > So looking for thoughts on how this can be implemented! > > Chetan Mehrotra > [1] > https://issues.apache.org/jira/browse/OAK-4412?focusedCommentId=15405340&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15405340 > > [2] Naming convention to be decided/discussed >
