uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-3722) JCasHashMap lifecycle size management broken
Date Thu, 03 Apr 2014 17:53:14 GMT

     [ https://issues.apache.org/jira/browse/UIMA-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marshall Schor updated UIMA-3722:
---------------------------------

    Description: 
The code which decides whether or not the map table expansion is needed does 
{code}
if (size >= sizeWhichTriggersExpansion) {
      increaseSize();
{code}
but fails to then recalculate sizeWhichTriggersExpansion... 

Additionally, the technique to save the last failed probe located empty cell is unreliable,
because arbitrary user code could be run which might disturb this value, in the case where
a new JCas cover class instance was constructed, and the class defined a "readObject()" method
- this would be called and could execute aribtrary operations.  Remove that optimization -
have the put operation always do the find-empty-slot.

  was:
The code which decides whether or not the map table expansion is needed does 
{code}
if (size >= sizeWhichTriggersExpansion) {
      increaseSize();
{code}
but fails to then recalculate sizeWhichTriggersExpansion... 


> JCasHashMap lifecycle size management broken
> --------------------------------------------
>
>                 Key: UIMA-3722
>                 URL: https://issues.apache.org/jira/browse/UIMA-3722
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.6.0SDK
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>             Fix For: 2.6.0SDK
>
>
> The code which decides whether or not the map table expansion is needed does 
> {code}
> if (size >= sizeWhichTriggersExpansion) {
>       increaseSize();
> {code}
> but fails to then recalculate sizeWhichTriggersExpansion... 
> Additionally, the technique to save the last failed probe located empty cell is unreliable,
because arbitrary user code could be run which might disturb this value, in the case where
a new JCas cover class instance was constructed, and the class defined a "readObject()" method
- this would be called and could execute aribtrary operations.  Remove that optimization -
have the put operation always do the find-empty-slot.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message