uimaj-core probably in good shape, testing invited

[Marshall Schor <ms...@schor.com>]

The trunk's version of uimaj-core is ready (I think) for some wider testing.

There's a temporary "recording" (1 line to System.out) in the CAS
deserialization code (which will be turned off shortly), that notifies when a
deserialization fixed a previously corrupting update - only occurs for "Delta
CAS" deserialization (used by UIMA-AS remote services, when returning a CAS to
its client, and only happens if the remote updated some existing FSs (not a
normal case).

The recent changes: turn on the index corruption FS updates detection, and if
found, automatically does the needed remove - addback around the feature update. 

There's a new global JVM property:  -Duima.report_fs_update_corrupts_index which
if defined will write UIMA log entries (to the UIMA log) every time the code
detects and fixes up a (previously illegal) update to a feature value (used as a
key, while the FS was in some index).

When I turned this on, besides a new test case (which tested this function), I
got errors generated by the core framework around DocumentAnnotation updates. 
So some needed fixes to handle that were also checked in :-)

I'd be interested to hear what people might experience, when running with this
-Duima.report_fs_update_corrupts_index JVM property.

-Marshall
 

Re: uimaj-core probably in good shape, testing invited

[Marshall Schor <ms...@schor.com>]

ok, sounds like a good idea, thanks!  I'll add it.

This will not fail if the users are doing the explicit protectIndices.

-Marshall
On 12/12/2014 4:37 PM, Richard Eckart de Castilho wrote:
> On 12.12.2014, at 19:06, Marshall Schor <ms...@schor.com> wrote:
>
>> I'd be interested to hear what people might experience, when running with this
>> -Duima.report_fs_update_corrupts_index JVM property.
> Although not needed anymore, I think it would be nice to keep the option to 
> -Duima.FAIL_fs_update_corrupts_index for some more time.
>
> E.g. instead of using -Duima.report_fs_update_corrupts_index in a Jenkins build
> and scanning through the log output, one could still fast-fail on such updates
> in Jenkins builds.
>
> That said, DKPro Core trunk builds are on UIMA trunk for a while now :)
> I'll chime in should they fail due to changes in the UIMA core.
>
> Cheers,
>
> -- Richard
>
>
>

Re: uimaj-core probably in good shape, testing invited

[Richard Eckart de Castilho <re...@apache.org>]

On 12.12.2014, at 19:06, Marshall Schor <ms...@schor.com> wrote:

> I'd be interested to hear what people might experience, when running with this
> -Duima.report_fs_update_corrupts_index JVM property.

Although not needed anymore, I think it would be nice to keep the option to 
-Duima.FAIL_fs_update_corrupts_index for some more time.

E.g. instead of using -Duima.report_fs_update_corrupts_index in a Jenkins build
and scanning through the log output, one could still fast-fail on such updates
in Jenkins builds.

That said, DKPro Core trunk builds are on UIMA trunk for a while now :)
I'll chime in should they fail due to changes in the UIMA core.

Cheers,

-- Richard