[
https://issues.apache.org/jira/browse/UIMA-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-4100.
----------------------------------
Resolution: Fixed
> deserialization of delta CASes broken in some cases
> ---------------------------------------------------
>
> Key: UIMA-4100
> URL: https://issues.apache.org/jira/browse/UIMA-4100
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.6.0SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 2.7.0SDK
>
>
> Delta CAS serialization includes attempting to handle changes made by a
> remote "below the line" - changing existing FSs. If the remote removes the
> FSs and re-adds them back to the indices, this fact is sent back with the
> delta CAS as a list of FSs that are "re-indexed". The deserialization takes
> this list, and removes them, and re-adds them back to the indices in an
> attempt to get them properly indexed. However, this doesn't reliably work,
> if any of the keys used in the indexing were updated.
> Furthermore, there is nothing that insures a remote remove/add FSs it is
> modifying. Perhaps the remote is unaware that FSs of that type are even
> being indexed (the information about what indices are defined at the client
> is not sent to the remote).
> So, it is possible that the remote could modify some feature, which is used
> as a key by the client. The Deserialization would update that feature,
> without removing the FS from the indices first.
> One conclusion - the list of "re-indexed" FSs returned by the remote during a
> delta serialization is not a reliable indication of which FSs would need
> reindexing, since the index definitions between the client and the remote
> could be different.
> One fix: for mods to existing FSs, remove the FS from the indices in each
> view, do the mods, and then add them back (if they were previously found in
> the indices for that view). Some optimizations: for subtypes of
> AnnotationBase - only one view need be checked. The remove could be skipped
> if none of the slots being updated are in use as keys in some index; this
> might be an expensive check, though.
> This is a problem for all implementations that support Delta CAS: Xmi,
> Binary, BinaryCompressed types 4 and 6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)