[
https://issues.apache.org/jira/browse/SLING-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838520#comment-16838520
]
Julian Sedding commented on SLING-8407:
---------------------------------------
Imagine the following code in e.g. {{JobManager}} to ensure an index for its
query is available:
{code:java}
@Reference(target = "(query=SELECT * FROM [nt:base] WHERE prop = ?)")
IndexReady indexReady;
{code}
Of course it's out of the question a service could be registered for each
conceivable query. However, the OSGi core spec describes [55.3.2 Providing a
Service on
Demand|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45721]
using a [55.6 Listener
Hook|https://osgi.org/specification/osgi.core/7.0.0/framework.servicehooks.html#d0e45955].
Oak could register a listener hook and test if an index is available to satisfy
the query from the filter expression. If that's the case, a matching
{{IndexReady}} instance could be registered to signal this fact.
Such a mechanism could handle both XPath and JCR-SQL2 queries and would make it
extremely simple to solve the same issue in other places as well. Drawback: it
would require Jackrabbit/Oak API and would not work with JCR implementations
that don't have this signalling mechanism.
I don't know what would be required inside Oak to make a meaningful test, but I
trust [~tmueller] or [~catholicon] could tell without too much research.
> JobManagerImpl.findJobs should prevent traversal
> ------------------------------------------------
>
> Key: SLING-8407
> URL: https://issues.apache.org/jira/browse/SLING-8407
> Project: Sling
> Issue Type: Improvement
> Components: Event
> Reporter: Thomas Mueller
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method
> [JobManagerImpl.findJobs|https://github.com/apache/sling-org-apache-sling-event/blob/master/src/main/java/org/apache/sling/event/impl/jobs/JobManagerImpl.java#L373]
> runs a JCR query to find all jobs for a topic.
> It is possible that such a query is running while the repository isn't
> initialized yet, meaning while the index isn't available yet. What is
> happening in this case is that the query is traversing all nodes below that
> path, triggering a warning that the query doesn't use an index. It is
> sometimes happening when a health check is running before the repository is
> initialized (ReplicationQueueHealthCheck and DistributionQueueHealthCheck).
> It doesn't make sense that the query traverses the nodes. It should use an
> index. If the index isn't available yet, it should fail. Therefore, the query
> should use "option(traversal fail)". That would result in an exception that
> can be caught. I will log a related issue to change the health checks to
> process this exception and return HEALTH_CHECK_ERROR for this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
