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] [Commented] (UIMA-4059) Checking for incorrect key modifications
Date Mon, 08 Dec 2014 14:52:12 GMT

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

Marshall Schor commented on UIMA-4059:
--------------------------------------

This has evolved with the realization that the Framework ought to support protecting indices,
since the remove / addback operation is potentially complex, and optimizable.  Complex: the
remove must be over all views where the item may be indexed; the remove can exclude bag indices
(because they have no keys), and if allow-multiple-add-to-indices are allowed, a count needs
to be maintained when removing and used when adding back (and multiple removes need to happen,
until all identical instances are removed). optimizable - the remove only needs to be done
if the FS is in the index, and we can cache the fact it's not in the index which covers the
most common cases; and the remove and add can skip bag indices.

Support for this is in UIMA-4135.  Instead of throwing exceptions, the check would be better
if it operated in "automatic" mode - where it automatically does the right remove/addback
operation, and (optionally) gives a report.

This design would have the following modes:

1) high performance - no runtime-checks for corruption, as was the case prior to 2.7.0.  
But the user could implement protectIndices blocks or try-finally blocks to do the optimized
remove/addbacks.

2) automatic, with or without reporting.  This would replace the earlier design of this Jira,
so instead of throwing an exception, it would report a Warning, and then proceed to automatically
"handle" it.  Users not concerned with high performance could run with this mode without reporting.
 Users concerned with high performance would get the report, implement their own "fixes" to
the reported issues (including implementing protectIndices blocks / try - finally blocks around
the reported spots), and then, run in #1 high performance mode.

Users running with automatic and with their own protectIndices blocks or try-finally blocks
might be "rechecking" their pipeline to see if other things have crept in.  To make this work,
automatic would be "turned off" within a protected area.  

> Checking for incorrect key modifications
> ----------------------------------------
>
>                 Key: UIMA-4059
>                 URL: https://issues.apache.org/jira/browse/UIMA-4059
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 2.7.0SDK
>
>
> Address the issue raised in Jira UIMA-4049, as follows: Add an optional check that checks,
for every set of a Feature value, whether or not that Feature is used as a key in any Sort
or Set index, and if so, if the Feature Structure is currently in any index in any View; if
so, an exception is thrown.  
> This additional check is normally disabled, but can be enabled by specifying the JVM
property {{-Duima.check_fs_update_corrupts_index}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message