You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Mario Juric (Jira)" <de...@uima.apache.org> on 2020/10/14 11:11:00 UTC

[jira] [Created] (UIMA-6273) isBeforeV3 variable not reset in BinaryCasSerDes

Mario Juric created UIMA-6273:
---------------------------------

             Summary: 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.1.1SDK, 3.1.0SDK, 3.0.2SDK, 3.0.0SDK, 3.0.1SDK
            Reporter: Mario Juric


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)