[
https://issues.apache.org/jira/browse/UIMA-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-6273.
----------------------------------------------
Resolution: Fixed
> isBeforeV3 variable not reset in BinaryCasSerDes
> ------------------------------------------------
>
> Key: UIMA-6273
> URL: https://issues.apache.org/jira/browse/UIMA-6273
> Project: UIMA
> Issue Type: Bug
> Components: uimaj
> Affects Versions: 3.0.1SDK, 3.0.0SDK, 3.0.2SDK, 3.1.0SDK, 3.1.1SDK
> Reporter: Mario Juric
> Assignee: Richard Eckart de Castilho
> Priority: Major
> Fix For: 3.2.0SDK
>
>
> This issue that took some time to track down, but I think we finally managed
> to identify the problem. It seems that the variable isBeforeV3 was introduced
> with UIMA3, but it is never cleared when the CAS is reset, i.e. the flag is
> not set to false again in the BinaryCasSerDes clear method. This means if the
> CAS instances are recycled, as it is the case with the CPE, that the value
> will never be false again after it has once been set to true.
>
> We ran into the issue with some integration tests that verified loading of
> our older CAS binaries, and they worked well until we introduced an UIMA 3
> version of the CAS binary into the tests. The error was strange because it
> seemed a bit random at first without being random, until we discovered that
> the error didn’t show up if the CAS was loaded within the first 3 tests.
> Turns out that the CPE recycles 3 CAS’es when a single thread is active, so
> if the test ran as one of the first 3 then it would start with a fresh CAS
> where isBeforeV3 is always false. Once it ran as number 4 or later then
> isBeforeV3 would be true, because all other tests were CAS binaries created
> under UIMA 2. The strange thing was that it never caused any exception, it
> just loaded the CAS with most annotations missing, so this added to the
> initial confusion.
>
> Resetting isBeforeV3 in the clear method solves the issue for our part, but
> it also requires that the variable is initialised later in the reinit method
> of BinaryCasSerDes, since it could be reset to false when the delta flag is
> false, and this can also cause failures during loading of earlier CAS
> versions than v3. The isBeforeV3 flag is not accessed before
> deserializeAfterVersion is invoked, and this only occurs inside this reinit
> method, so this additional change should not cause any unwanted side effects.
>
> I am not sure if there are other variables that need to be reset when the CAS
> is reset, but I think it may be necessary to go through them to see if
> something else has been missed. This issue affects all versions since at
> least UIMA 3 was released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)