[
http://jira.magnolia.info/browse/MAGNOLIA-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146#action_17146
]
Jan Haderka commented on MAGNOLIA-2152:
---------------------------------------
{quote}
To bring them in synch again we have worked out the following procedure:
* export the nodes
* delete then nodes
* restart the server
* import the nodes
Simply exporting, deleting and then importing did not fix the issue.
{quote}
Seems to me like something kills the indexer. In your configuration
{code}
<param name="extractorPoolSize" value="3" />
<param name="extractorTimeout" value="100" />
<param name="extractorBackLogSize" value="100" />
{code}
you are using 3 indexers running on the background asynchronously. If the issue
was simple failing to index the data, you should see the exception in the logs.
If the indexing slows down it will be cancelled after the timeout (value is in
miliseconds).
You could try two things at this point:
* increase the timeout, so the indexer has more time to index the content. It
won't fix the issue, just decrease probability of it to manifest itself.
* set pool size to 0 so all the indexing is done on main thread (saving content
will be slower, but if there is problem with the content you will see it as a
blockage so you can figure out saving which piece of content triggers the
behaviour.
The question is why should indexing slow down permanently (so once it happens
document will always timeout before it can be indexed) and why should it get up
to speed after restart ... you might be hitting some underlying issue with
either JackRabbit or Lucene.
> QueryManager and JCR browser seem to have different view on repository
> ----------------------------------------------------------------------
>
> Key: MAGNOLIA-2152
> URL: http://jira.magnolia.info/browse/MAGNOLIA-2152
> Project: Magnolia
> Issue Type: Bug
> Components: core
> Affects Versions: 3.5.8
> Reporter: Philippe Marschall
> Assignee: Philipp Bracher
>
> We have a very strange issue with querying custom page attributes. We have a
> custom page dialog that sets some custom page properties. These attributes
> are ad hoc and not defined in some sort of schema. We then have observation
> code that queries the JCR for pages with these attributes and certain values.
> Our queries look like this:
> {code}
> //element(*, mgnl:content) [EMAIL PROTECTED] and @someLongAttribute != 0]
> {code}
> {code}
> SELECT *
> FROM mgnl:content
> WHERE someLongAttribute IS NOT NULL AND someLongAttribute != 0
> {code}
> {code}
> //element(*, mgnl:content) [EMAIL PROTECTED] and @someBooleanAttribute =
> 'true']
> {code}
> {code}
> SELECT *
> FROM someBooleanAttribute IS NOT NULL AND someBooleanAttribute = 'true'
> {code}
> The behavior we are observing is that for certain pages the check for an
> attribute value is always false even if it should match according to the JCR
> browser. However the check for the attribute presence works as expected. As
> soon as we change a page attribute in the JCR browser the checks for the
> values work even if changed with the page properties dialog.
> This issue is very rare and we have not yet found a way to reproduce or
> trigger it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia.info/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
