Re: javax.jcr.RepositoryException 1252: unable to update item

[Marcel Reutegger <ma...@gmx.net>]

Stefan Guggisberg wrote:
> On 7/27/05, Richard Osbaldeston <ri...@wordmap.com> 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

Re: javax.jcr.RepositoryException 1252: unable to update item

[Stefan Guggisberg <st...@gmail.com>]

On 8/8/05, Marcel Reutegger <ma...@gmx.net> wrote:
> Stefan Guggisberg wrote:
> > On 7/27/05, Richard Osbaldeston <ri...@wordmap.com> 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?

absolutely correct. i have no idea how you could get into such a situation.
i need more information to further investigate this problem.

richard,
please try the steps that i had repeatedly suggested previously in this 
thread.

cheers
stefan


> 
> regards
>   marcel
>