[
https://issues.apache.org/jira/browse/OAK-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849788#comment-16849788
]
Thomas Mueller commented on OAK-8343:
-------------------------------------
One of the first queries is actually run when initializing the repository, when
there are few (almost no) indexes available:
{noformat}
select [rep:Authorizable].[rep:authorizableId] as
[rep:Authorizable.rep:authorizableId], [rep:Authorizable].[rep:principalName]
as [rep:Authorizable.rep:principalName], [rep:Authorizable].[jcr:uuid] as
[rep:Authorizable.jcr:uuid], [rep:Authorizable].[jcr:primaryType] as
[rep:Authorizable.jcr:primaryType], [rep:Authorizable].[jcr:createdBy] as
[rep:Authorizable.jcr:createdBy], [rep:Authorizable].[jcr:created] as
[rep:Authorizable.jcr:created] from [rep:Authorizable] as [rep:Authorizable]
where [rep:Authorizable].[rep:principalName] = $principalName
Daemon Thread [Apache Sling Repository Startup Thread] (Suspended (breakpoint
at line 319 in IndexTracker))
IndexTracker.waitForIndex(NodeState, String) line: 319
IndexTracker.getIndexDefinition(String, boolean) line: 287
LucenePropertyIndex$LazyLuceneIndexNode.getDefinition() line: 1615
LucenePropertyIndex$LazyLuceneIndexNode.getDefinition() line: 1580
FulltextIndexPlanner.<init>(IndexNode, String, Filter,
List<OrderEntry>) line: 102
LucenePropertyIndex(FulltextIndex).getPlans(Filter, List<OrderEntry>,
NodeState) line: 102
QueryImpl.getBestSelectorExecutionPlan(NodeState, FilterImpl,
QueryIndexProvider, boolean) line: 1015
QueryImpl.getBestSelectorExecutionPlan(FilterImpl) line: 968
SelectorImpl.prepare() line: 308
QueryImpl.prepare() line: 629
MutableRoot$2(QueryEngineImpl).prepareAndSelect(List<Query>) line: 304
MutableRoot$2(QueryEngineImpl).executeQuery(String, String, long, long,
Map<String,PropertyValue>, Map<String,String>) line: 278
UserProvider.getAuthorizableByPrincipal(Principal) line: 231
UserManagerImpl.getAuthorizable(Principal) line: 126
UserManagerImpl.checkValidPrincipal(Principal, boolean) line: 457
UserManagerImpl.createUser(String, String, Principal, String) line: 163
UserManagerImpl.createUser(String, String) line: 156
UserInitializer.initialize(NodeBuilder, String) line: 144
OakInitializer.initialize(Iterable<WorkspaceInitializer>, NodeStore,
String, CommitHook) line: 60
Oak.initialContent(IndexEditorProvider, QueryIndexProvider) line: 697
Oak.createNewContentRepository() line: 725
Oak.createContentRepository() line: 670
Jcr.createContentRepository() line: 376
SlingRepositoryManager.createRepository() line: 443
SlingRepositoryManager.acquireRepository() line: 284
SlingRepositoryManager(AbstractSlingRepositoryManager).initializeAndRegisterRepositoryService()
line: 471
AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager) line:
85
AbstractSlingRepositoryManager$4.run() line: 455
{noformat}
> Allow queries to be delayed until an index is available
> -------------------------------------------------------
>
> Key: OAK-8343
> URL: https://issues.apache.org/jira/browse/OAK-8343
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-8343-b.patch, OAK-8343.patch
>
>
> Currently, indexes are built asynchronously. That is, if an index definition
> is added, the index is eventually built, but it's quite hard to say when it
> is ready for queries. This can be specially a problem right after the initial
> repository initialization, or after an upgrade.
> In theory, system startup could be delayed until all indexes are ready (e.g.
> set the "reindex" flag for important indexes, and at startup, wait until the
> "reindex" flag is set to "false"). However, doing that would block threads
> that _don't_ need an index. It would be better to only block threads that
> actually do run queries. That would make startup deterministic, without
> delaying other threads unnecessarily.
> To solve the problem, we can add a property "waitForIndex" in the index
> definition (just Lucene indexes is fine for now, as those are the important
> asynchronous ones). If set, then queries that potentially use those indexes
> are delayed, until the indexes are ready for sure. Reindex would need to
> remove that property (the same as it removes e.g. refresh or sets reindex to
> false). For added security, queries are only blocked as long as "reindex" is
> also set to true (this ensures that waitForIndex is removed eventually), and
> waiting should time out after 2 minutes, to ensure the feature doesn't block
> startup forever if indexing fails for some reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
