[ 
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)

Reply via email to