[
https://issues.apache.org/jira/browse/UIMA-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-4820.
----------------------------------
Resolution: Fixed
> uv3 Supporting Delta deserialization requires preserving simulated heap
> addresses
> ---------------------------------------------------------------------------------
>
> Key: UIMA-4820
> URL: https://issues.apache.org/jira/browse/UIMA-4820
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 3.0.0SDKexp
>
>
> UIMA supports various formats of delta deserialization, which is when a
> serialization is done (to, for example, a remote service), and then a delta
> serialization returns just the changes back to the original CAS.
> There are two approaches used to get the set of FSs to serialize.
> * One way, used for plain binary and form4 compressed, scans the "heap"
> sequentially, and sends all those FSs, including potentially FSs that are not
> "reachable".
> * The other way is to use the indexes plus following reference chains to
> locate all "reachable" FSs, and only send those. This is used for XCAS, XMI,
> JSON, and Form6 compressed.
> In V3, the plain and form4 serialization need to preserve simulated heap
> "addresses" (per CAS) for the FSs sent in order to enable future delta
> deserializations to have the proper "heap" addresses; it may not recalcuate
> this from the CAS FS contents, because intervening GCs may have garbage
> collected some unreachable FSs..
> Furthermore, plain and form4 non-delta deserialization where a delta
> serialization is to follow, must likewise preserve these simulated heap
> addresses (per CAS), for all deserialized FSs.
> This preservation is needed to insure that the simulated "addresses" of FSs
> are constant, even if unreachable FSs are reclaimed. In practice, this means
> that various maps involving simulated heap "addresses" need to be retained
> and not recreated.
> Because they are retained, their storage needs to be released when no longer
> needed: at CAS Reset time, after a services delta deserializer has completed
> deserializing (potentially multiple) delta CASes, or when a new non-delta
> serialization is started (this will re-create this storage). For services
> use, we may add a new API to release this storage; the service would call it
> after all delta deserializations for this CAS have been received (this use
> case is supporting having multiple remotes working on a common CAS and having
> their delta results merged back into the original CAS).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
