[
https://issues.apache.org/jira/browse/SLING-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188313#comment-16188313
]
Konrad Windszus edited comment on SLING-7169 at 10/2/17 3:24 PM:
-----------------------------------------------------------------
In case of failure something like this can be observed in the error.log
{code}
02.10.2017 13:14:50.655 *INFO* [127.0.0.1 [1506939290651] GET
/testing/fullTextQuery HTTP/1.1] org.apache.jackrabbit.oak.query.QueryImpl
Traversal query (query without index): SELECT * FROM [nt:base] AS s WHERE
CONTAINS(s.*, $queryText); consider creating an index
{code}
In case of a successful execution of that IT that error isn't logged. So it
seems to me that sometimes Oak is not using the internal index for the query
and falling back to the traversal mechanism which obviously times out:
During the startup of the server the following is logged:
{code}
02.10.2017 13:13:47.535 *INFO* [async-index-update-async]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be
performed for following indexes: [/oak:index/counter, /oak:index/lucene]
{code}
but the according completion message cannot be observed. While for successful
runs I see something like this
{code}
02.10.2017 14:04:36.561 *INFO* [async-index-update-async]
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] Reindexing
completed for indexes: [/oak:index/counter*(16), /oak:index/lucene*(2166)] in
1.269 s
{code}
Seems that this particular IT needs to wait for the reindexing to be finished
first before it should be executed.
was (Author: kwin):
In case of failure something like this can be observed in the error.log
{code}
02.10.2017 13:14:50.655 *INFO* [127.0.0.1 [1506939290651] GET
/testing/fullTextQuery HTTP/1.1] org.apache.jackrabbit.oak.query.QueryImpl
Traversal query (query without index): SELECT * FROM [nt:base] AS s WHERE
CONTAINS(s.*, $queryText); consider creating an index
{code}
In case of a successfull execution of that IT that error isn't logged. So it
seems to me that sometimes Oak is not using the internal index for that query
for some reason.
Something like this can also be observed during startup:
{code}
02.10.2017 13:13:47.535 *INFO* [async-index-update-async]
org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be
performed for following indexes: [/oak:index/counter, /oak:index/lucene]
{code}
but the according completion message does not happen. While for successfull
runs I see something like this
{code}
02.10.2017 14:04:36.561 *INFO* [async-index-update-async]
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] Reindexing
completed for indexes: [/oak:index/counter*(16), /oak:index/lucene*(2166)] in
1.269 s
{code}
So to me it seems, that this particular IT needs to wait for the reindexing to
be finished first.
> FullTextIndexingTest sometimes fails with a timeout
> ---------------------------------------------------
>
> Key: SLING-7169
> URL: https://issues.apache.org/jira/browse/SLING-7169
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
> Reporter: Robert Munteanu
> Labels: sling-IT
> Attachments: SLING-7169-logs.tar.gz
>
>
> The test fails maybe 1 in 10 runs. I could reproduce this locally by running
> many times. I've also seen it once on Jenkins.
> **Old description below**
> After upgrading the launchpad to commons.threads 3.2.10 the
> FullTextIndexingTest failed ( [build
> 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ).
> I also reproduced it once locally.
> [~kwin] - since the commons.threads release is the potential root cause, can
> you please take a look at the failure and see if it's related?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
