[ 
https://issues.apache.org/jira/browse/UIMA-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213841#comment-17213841
 ] 

Mario Juric commented on UIMA-6273:
-----------------------------------

A PR for a suggested fix has been made: 
https://github.com/apache/uima-uimaj/pull/66

> 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
>            Priority: Major
>
> 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)

Reply via email to