>
> Primarily concerned with the index repository. First of all, I don't
>> understand how multiple annotators could be iterating over an index that
>> other annotators are modifying at the same time.
>>
>
> This is the magic of the concurrent collection classes in the java SDK :)
> The iterators are not guaranteed to "see" concurrent modifications, but by
> definition that does not matter if the annotators in question are suitable
> to run in parallel.
>
The point here is that implementing index protection might be impossible
if multiple threads are updating the same index repository. "Suitable" might
be restricted to annotators that do not update any index.
>
> Secondly, Marshall has
>> spent much time making an index robust to inadvertent user changes. For
>> example an annotator modifies some "key" feature values for an indexed FS,
>> or [even impossible to know] modifies feature values that another
>> annotator
>> has used as keys in a custom index. These scenarios are now detected and
>> automatically fixed under the covers, but both require looking across all
>> indexes in all views at the same time. Allowing multiple annotators to
>> operate R/W on a common index repository would preclude both automatic
>> fixup and detection.
>>
>
> As mentioned automatic "index protection" is one of the things I hadn't
> yet included since it was added very recently - from what I understand it's
> always been an issue but hasn't caused noticeable problems. It should not
> be a problem to support this in a similar way with the new implementation.
>
A problem associated with index corruption was reported:
https://issues.apache.org/jira/browse/UIMA-4049
I suspect that others have had similar problems (e.g. duplicate annotations)
but since these things are hard to recognize much less understand,
users didn't spend the time to debug, or worse might have given up on UIMA.
Eddie
