Stefan Guggisberg wrote:
On 7/27/05, Richard Osbaldeston <[EMAIL PROTECTED]> wrote:
Almost looked like JackRabbit suddenly restated itself mid-way through
populating the repository? or is that just a quirk of the exception
ordering? The "Found uncommitted redo log. Applying changes now..." and
the "java.lang.ArrayIndexOutOfBoundsException: 0" from lucene seemed
suspicious, especially as I'd thought indexing would be disabled by
removing the indexing configuration from the repository.xml ..maybe
thats the difference? Need to do more digging..
repository.xml is just the template to use when creating new workspaces.
once a workspace is created it uses its own workspace.xml configuration.
if you want to disable query support in an existing workspace you have
to comment the config there.
ok, the only thing that i can tell from the stack trace is that lucene's index
seems to be corrupt, probably due to an abnormal process termination.
the uncommitted redo log does not mean that the index is currupt but
that it is not in sync with the workspace data. the cause for this is
most certainly an abnormal process termination. if on startup the index
detects that it is not in sync it will re-index the missing nodes.
That seems to be the case in your setup. However I don't think that the
ArrayIndexOutOfBoundsException is the fault of the NodeIndexer. A single
value property state should not be allowed to have no value.
<snip from="NodeIndexer.java" line="282">
PropertyState encodingProp = (PropertyState)
stateProvider.getItemState(new PropertyId(node.getUUID(), JCR_ENCODING));
encodingProp.getValues()[0].internalValue().toString();
</snip>
That is, the second line should never throw an
ArrayIndexOutOfBoundsException.
WDYT Stefan?
regards
marcel
