[
https://issues.apache.org/jira/browse/UIMA-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378459#comment-15378459
]
Marshall Schor commented on UIMA-4743:
--------------------------------------
Proposal for introducing this fix, addressing client-server usage (e.g.,
UIMA-AS), and serialization/deserialization to disk
* Observations and assumptions:
* The new code can read old-or-new serialized forms (because the forms
are self-identifying
* The old code cannot read new form, and won't know this, and may fail in
arbitrary ways.
* For client - server, if the client is new and the server is old, there's
no issue because the client doesn't send a delta cas.
* if the client is old and the server is new, the service will know it's
receiving the old format and can then respond with the old format
* For writing to disk, I think it is unlikely that there are delta cas
writes to disk, since they have no meaning except with respect to a main CAS,
as part of a service scenario.
* Disk serialization would most likely be in other formats (XMI, JSON, or
compressed binary).
So, I think it is reasonable to put this fix out in the next release, as long
as the new code can read both the new and old formats (which it can).
What do people think?
> errors in plain binary cas delta serialization of short/long modifications to
> arrays
> ------------------------------------------------------------------------------------
>
> Key: UIMA-4743
> URL: https://issues.apache.org/jira/browse/UIMA-4743
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.8.1SDK
> Reporter: Marshall Schor
> Fix For: 2.8.2SDK
>
>
> (Found by code reading, needs test case) The code for handling long/dbl value
> modified cells while doing delta serialization appears to have a some
> copy/paste kinds of errors. The first (line 583) gets the modified addrs, but
> gets the "short" rather than "long" addrs. The second (line 587) writes the
> address of the modified value using a writeShort, which silently fails if the
> value is > 32767.
> This same kind of error (writing the address as a short) also appears in the
> handling of modifications of shorts (line 570).
> Fixing this will result in writing more bytes to the serialization stream, so
> the streams won't be "compatible". Therefore, do some kind of incrementing
> of versions and serialVersionId values to signal to readers this format
> change. Updating this for client/server pairs will require updates at both
> ends.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
