You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@uima.apache.org by sc...@apache.org on 2014/12/15 20:05:27 UTC
svn commit: r1645723 - in /uima/uimaj/trunk: README RELEASE_NOTES.html
Author: schor
Date: Mon Dec 15 19:05:27 2014
New Revision: 1645723
URL: http://svn.apache.org/r1645723
Log:
[UIMA-4135] update readme / release notes to current impl state
Modified:
uima/uimaj/trunk/README
uima/uimaj/trunk/RELEASE_NOTES.html
Modified: uima/uimaj/trunk/README
URL: http://svn.apache.org/viewvc/uima/uimaj/trunk/README?rev=1645723&r1=1645722&r2=1645723&view=diff
==============================================================================
--- uima/uimaj/trunk/README (original)
+++ uima/uimaj/trunk/README Mon Dec 15 19:05:27 2014
@@ -37,14 +37,24 @@ What's New in 2.7.0
The old behavior may be restored, if needed for backward compatibility by defining the JVM property
uima.allow_duplicate_add_to_indices; see the UIMA Reference documentation Chapter 10.
- There is a new kind of check that may be optionally enabled in UIMA (by defining the JVM argument
- "-Duima.check_fs_update_corrupts_index") that checks all modifications to features to see if that feature is
- being used as a key in a Sort or Set index, and the Feature Structure being modified is currently in
- one or more indices (Jira issue UIMA-4059). Doing such a modification can cause the index to become corrupt.
- (The correct way to do an update in this case is to
- first remove the Feature Structure from the indices,
- do the modification,
- and then add it back to the indices.)
+ To prevent potential index corruption, UIMA now recovers (unless disabled by ("-Duima.protect_indices_from_key_updates=false"))
+ from all illegal modifications of features.
+
+ These are modifications to features used as index keys, done while the Feature Structure being modified is currently in
+ one or more indices (Jira issue UIMA-4135).
+
+ Corruption is prevented by doing the needed removes and addbacks to Set and Sorted indices.
+ Because the recovery can affect performance, it is recommended that you run with JVM property
+ "-Duima.report_fs_update_corrupts_index" in order to see if any user code has this problem, and fix these via
+ redesign, or by wrapping the affected areas with a form of protectIndices() (see the CAS Javadocs).
+
+ A long-standing difficulty with Feature Structure iterators, namely, that adding to / removing from the underlying
+ index being iterated over is not allowed while iterating, is addressed with a new class of "snapshot" iterators.
+ These take a snapshot of the state of the index when the iterator is created; subsequent modifications to the index
+ are then permitted, while the iterator continues to iterate over the snapshot it created; these iterators do not
+ throw ConcurrentModificationException. The implementation of this feature is via a new method on FSIndex, which
+ creates a light-weigh copy of the the FSIndex instance, where getting iterators gets the Snapshot kind. This approach
+ allows using the new index in Java's "extended for" statement.
There are many bug fixes. Some highlights:
- making the JCasGen Eclipse plugin work with more varieties of specifications for class paths. Jira issues: UIMA-4080/4081
@@ -54,7 +64,6 @@ What's New in 2.7.0
The complete list of fixes is here: issuesFixed/jira-report.hmtl
-
Backward Compatibility Accommodations
------------------------------------
@@ -66,8 +75,7 @@ Backward Compatibility Accommodations
for UIMA that can restore earlier behaviors.
The UIMA References documentation (see http://uima.apache.org/documentation.html)
has a table of these in Chapter 10.
-
-
+
Supported Platforms
--------------------
Modified: uima/uimaj/trunk/RELEASE_NOTES.html
URL: http://svn.apache.org/viewvc/uima/uimaj/trunk/RELEASE_NOTES.html?rev=1645723&r1=1645722&r2=1645723&view=diff
==============================================================================
--- uima/uimaj/trunk/RELEASE_NOTES.html (original)
+++ uima/uimaj/trunk/RELEASE_NOTES.html Mon Dec 15 19:05:27 2014
@@ -80,10 +80,11 @@
</p>
<h2><a name="major.changes">Major Changes in this Release</a></h2>
+<h3>Sorted and Bag indices no longer store multiple instances of identical FSs</h3>
<p>
The meaning of "bag" and "sorted" index has been made consistent with how these are handled
when sending CASes to remote services. This means that adding the same identical FS to the
-indexes, multiple times, will not add duplicate index entries. And, removing a FS from an index
+indexes, multiple times, will no longer add duplicate index entries. And, removing a FS from an index
is guaranteed that that particular FS will no longer be in any index. (Before, if you had
added a particular FS to a sorted or bag index, multiple times, the remove behavior would
remove just one of the instances). Deserialization of CASes sent to remote services has never
@@ -92,27 +93,33 @@ consistent. For more details, see <a tar
https://issues.apache.org/jira/browse/UIMA-3399</a>.
</p>
-<p>Because some users may prefer the previous behavior that permitted duplicates of identical Feature Structures in
+<p>Because some users may need the previous behavior that permitted duplicates of identical Feature Structures in
the sorted and bag indexes. this change can be disabled, by running the JVM with the defined property
"uima.allow_duplicate_add_to_indices".</p>
+<h3>JSON serialization support</h3>
<p>
JSON serialization support is added for Type System Descriptions, and for CASs.
Several formats for JSON CAS serialization are provided, please see the chapter in the
UIMA reference documentation for details.
</p>
-<p>There is a new kind of check that may be optionally enabled in UIMA (by defining the JVM argument
- "-Duima.uima.check_fs_update_corrupts_index") that checks all modifications to features to see if that feature is
- being used as a key in a Sort or Set index, and the Feature Structure being modified is currently in
- one or more indices (Jira issue UIMA-4059). Doing such a modification can cause the index to become corrupt.
- (The correct way to do an update in this case is to
- first remove the Feature Structure from the indices,
- do the modification,
- and then add it back to the indices.)</p>
+<h3>Index corruption avoidance</h3>
+<p>To prevent potential index corruption, UIMA now recovers (unless disabled by ("-Duima.protect_indices_from_key_updates=false"))
+ from all illegal modifications of features.</p>
+
+ <p>These are modifications to features used as index keys, done while the Feature Structure being modified is currently in
+ one or more indices (Jira issue UIMA-4135).</p>
+
+ <p>Corruption is prevented by doing the needed removes and addbacks to Set and Sorted indices.
+ Because the recovery can affect performance, it is recommended that you run with JVM property
+ "-Duima.report_fs_update_corrupts_index" in order to see if any user code has this problem, and fix these via
+ redesign, or by wrapping the affected areas with a form of protectIndices() (see the CAS Javadocs).</p>
+<h3>Java 7 minimum level</h3>
<p>Java 7 is now the minimum level of Java required.</p>
+<h3>Snapshot iterators, won't throw ConcurrentModificationException</h3>
<p>The fixed bugs include fixes to the UIMA iterator moveTo(FeatureStructure) and creation methods which
ended up doing a moveToFirst() if the Feature Structure was beyond the last element in the index;
the fixed code now marks the position of the iterator as invalid. Also, the positioning of these