[
https://issues.apache.org/jira/browse/UIMA-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284305#comment-14284305
]
Richard Eckart de Castilho commented on UIMA-3399:
--------------------------------------------------
Further debugging in
org.apache.uima.cas.impl.FSIndexRepositoryImpl.LeafPointerIterator.LeafPointerIterator(FSIndexRepositoryImpl,
IndexIteratorCachePair, int):
{noformat}
org.apache.uima.cas.impl.FSIndexRepositoryImpl.LeafPointerIterator.copy()
996: public Object copy() {
997: // If this.isValid(), return a copy pointing to the same element.
998: if (this.isValid()) {
999: return new LeafPointerIterator(this.iicp, this.get());
org.apache.uima.cas.impl.FSIndexRepositoryImpl.LeafPointerIterator.LeafPointerIterator(FSIndexRepositoryImpl,
IndexIteratorCachePair, int)
951: private LeafPointerIterator(IndexIteratorCachePair iicp, int fs) {
952: this(iicp);
953: moveTo(fs);
954: }
{noformat}
After 952, index.isValid() is still true, but after 953, index.isValid()
becomes false.
It looks definitely like a bug: the copy of a valid iterator becomes invalid,
but it should remain valid.
> More consistent handling of multiple add-to-index behavior for same Feature
> Structure
> -------------------------------------------------------------------------------------
>
> Key: UIMA-3399
> URL: https://issues.apache.org/jira/browse/UIMA-3399
> Project: UIMA
> Issue Type: Improvement
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 2.7.0SDK
>
>
> UIMA has a somewhat unusual indexing architecture. You can define indexes
> (sorted, bag, set), and then add / remove a feature structure (FS) to all of
> the defined indexes.
> The design intention (I think) was to support the concept of a FS being
> indexed, or not. However, the current design allows some anomalies that
> behave inconsistently between code being run "locally", versus as remote
> services (due to how serialization handles this). Serialization encodes only
> the concept of a FS being either in an index or not.
> The problem arises in the edge case where the same identical FS is added to
> the indexes multiple times. For local (non-remote) cases, for bag and sorted
> indexes, the same exact FS would be added multiple times. This would have
> the consequences:
> - Iterating would return multiple == FSs.
> - Remove from indexes of a multiply-added FS would reduce the number by 1;
> the FS would still be in the index unless the last remaining one was removed..
> For the same code, running remotely, serialization would have "collapsed" the
> multiple additions into one, so would behave differently.
> This Jira changes the behavior of "add-to-index" so that subsequent
> add-to-indexes of a same identical FS would be a no-op. To cover users who
> might be exploiting the old behavior, the JVM property
> "uima.allow_duplicate_add_to_indices", read when the UIMA classes are loaded,
> would restore the previous behavior.
> Note that with this change, the UIMA "Set" index still has a distinct purpose
> , separate from the "Bag" index, because it defines Feature Structure
> equivalence based not on identity, but rather on specified key feature values
> being equal.
> This change better aligns how code running locally or remotely works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
