jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alessandro Bologna" <alessandro.bolo...@gmail.com>
Subject Re: XPATH problem
Date Tue, 01 Apr 2008 12:10:01 GMT
We had experienced something like this a few times.

In most cases was enough to shutdown Jackrabbit, delete the contents of the
repository/workspaces/<name>/index directory (for each workspace if you more
than one) and start Jackrabbit again. It will re-index all the contents, and
it should be faster and less troublesome than exporting/importing again.
Depending on how much data you have loaded, the process could take from a
few minutes to a few hours.

Hope it helps.

On Tue, Apr 1, 2008 at 7:41 AM, Juerg Meier <juerg.meier@ctp-consulting.com>

> Just for completeness...
> I had to reload the JCR from ground-up (export - remove repository -
> import), now it works again.  And I really hope this won't happen in
> production...
> -- Juerg
> ________________________________________
> From: Juerg Meier [juerg.meier@ctp-consulting.com]
> Sent: Monday, March 31, 2008 3:19 PM
> To: users@jackrabbit.apache.org
> Subject: XPATH problem
> Hi,
> I have a problem in category "query should return something, but it
> doesn't", too.
> One subnode of the rep does not seem to be reachable anymore by xpath
> queries. The problem exists since I shut down my app, and temporarely
> startet magnolia. But I frankly cannot imagine that this can cause a problem
> of this sort.
> The situation is as follows:
> /
>  A (nt:unstructured)
>     A1 (nt:unstructured)
>     A2 (nt:unstructured)
>  B (nt:unstructured)
>     B1 (nt:unstructured)
>     B2 (nt:unstructured)
> The problem is that no query in the /A substree works anymore. They all
> return empty, including statements that have worked for months. Finally, I
> tested something like this:
> //element(*, nt:unstructed)
> This query returns all nt:unstructured nodes of B, but not of A! The
> behaviour is the same for both, application and query tools. I already
> rebuilt the index, but the effect is still the same.
> Question: could there be a Lucene internal lock? I consider that unlikely,
> the rebuild would have solved the problem. Or is there an inconcistence in
> the JCR that makes a correct indexing impossible? Also unlikely, as the node
> tree of A can be navigated without a problem through the JCR API.
> Thus, I'm pretty clouless. Anybody with an idea?
> Regards,
> Juerg

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message