uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Date Mon, 27 Jul 2009 01:24:01 GMT
Some tracing of the failure case on my machine.

The test prepares 100 FS, with begin/end pairs starting at 0/4, 5/9,
etc. Let's call these token(0,4) token(5,9) etc.

It inserts them into the indexes.

It removes the 0-eth one (OK).
It does a set iterator "moveTo(fsArray[i])", the one it removed.  This
might be suspect, because for Set indexes, our docs say "Set indexes do
not enforce ordering".  So moveTo(x) where x is not in the index seems
to be to be undefined, without a sort order.
The comment in the code for the moveTo(arg) method says:
   * Move the iterator to the first features structure that is equal to
<code>fs</code>. If no
   * such feature structure exists in the underlying collection, set the
iterator to the "insertion
   * point" for <code>fs</code>, i.e., to a point where the current
feature structure is greater
   * than <code>fs</code>, and the previous one is less than

Now, it turns out that the definition of the set index includes the
begin and end features in the same way as the normal index does, so
perhaps the code is "sorting" based on this, anyway.  The set index def
*does not* include TYPE PRIORITY as the 3rd element, however.  ( I don't
think that matters here, since all the begin/end vlaues are different).

The moveTo positions the iterator so that the next get() gets the token(5,9)

When the loop finixhes, it re-inserts the token(0,4) it had removed. 
This shows up in the fs index in the 0th position.

The error happens in the next loop.

The token(5,9) is removed from the set index, but when I look at the
index contents, instead of that one being removed, the token(80,84)
disappears from the set index!

When the request to move to token(5,9) is given, since that element is
still there, it moves to it. And then the test produces an assert error.

So, there may be 2 things to look at here - the actual error, described
above, and the more philosophical question on the behavior of moveTo -
this seems to require a sorting order if the item "moved to" is not
present in the index.  Perhaps this needs to be documented better.  And
what if no sorting order was defined for the set index? 


Marshall Schor wrote:
> I think this fix gives rise to another test case failure.  I backed out
> this fix, and the (I think new) test in IteratorTest - testIterator
> fails on line 357.
> With this fix restored, there is a failure on IteratorTest - testDelete,
> line 662.
> Thilo - I think you are the best person to investigate - can you take a
> look, please?
> -Marshall
> Thilo Goetz (JIRA) wrote:
>>      [ https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> Thilo Goetz closed UIMA-1352.
>> -----------------------------
>>        Resolution: Fixed
>>     Fix Version/s: 2.3
>> Fixed, and Pablo's test case added.  Pablo, please verify if possible.
>>> java.lang.ClassCastException using find() with a SET index
>>> ----------------------------------------------------------
>>>                 Key: UIMA-1352
>>>                 URL: https://issues.apache.org/jira/browse/UIMA-1352
>>>             Project: UIMA
>>>          Issue Type: Bug
>>>          Components: Core Java Framework
>>>    Affects Versions: 2.2.2
>>>         Environment: Linux openSUSE 10.2
>>>            Reporter: Pablo D.
>>>            Assignee: Thilo Goetz
>>>             Fix For: 2.3
>>>         Attachments: uima_test.zip
>>> It is not possible to use the FSIndex.find() method when the indexing strategy
is a SET.
>>> A java.lang.ClassCastException is thrown.
>>> For example:
>>> FSIndex idx = aJCas.getJFSIndexRepository().getIndex("idx_SET");
>>> while (doSomething) {
>>>    MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
>>>    myFs.setMyFeature(value);
>>>    myFs.addToIndexes();
>>>    // Try to recover from index    
>>>    MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs);  // ClassCastException
>>>    ...
>>> }

View raw message