Re: Type system commit race condition when maven builds jar(?)

[Andrew Trice]

The issue arose from using the Maven Assembly Plugin to naively build an 
executable jar with uimaFit components. Files supplied by different 
dependencies overwrote each other during packaging and some types could not be 
detected at runtime. The uimaFit documentation has this issue recorded in 
chapter 9: 
https://uima.apache.org/d/uimafit-current/tools.uimafit.book.html#ugr.tools.uimafit.packaging
 
.
 We resolved the issue using the Maven Shade Plugin as shown in the document.

Thanks,

Andrew
> On Aug 23, 2017, at 2:06 PM, Jean-Karlo Accetta  
> wrote:
> 
> Hi Marshall,
> 
> I work with Andrew. Thanks for the reply, this definitely helps!
> 
> Best regards,
> J.K. Accetta
> 
> 
> 
> On 8/23/17 8:50 AM, Marshall Schor wrote:
>> Hi,
>> 
>> Those two listing of the type system appear to show that the *working* 
>> version
>> does not have cTakes, and the *failing* version has cTakes.
>> 
>> Any ideas why this might be so?
>> 
>> The stack trace appears to show that the "FileSystemCollectionReader" class 
>> is
>> running the getNext method, and that is attempting to create an instance of 
>> the
>> JCas class   com.clinacuity.deid.annotations.DocumentInformationAnnotation.
>> 
>> The error message indicates that whatever causes the class
>> com.clinacuity.deid.annotations.DocumentInformationAnnotation to be "loaded" 
>> &
>> "initialized" by Java's class loader is happening before the type system has
>> been committed.
>> 
>> It seems that the FileSystemCollectionReader is being run in some separate
>> thread.  If your system design is permitting this to happen in a race with
>> another thread which is setting up the type system and committing it, you 
>> could
>> get this error.  The fact that a big type system might take longer to set up
>> might account for why that one fails (the shorter one wins the race).
>> 
>> Of course, for reliable operation, the race must be eliminated; a fix would 
>> be
>> to delay starting threads that depend on the type system, until the type 
>> system
>> has been committed.
>> 
>> Does this help?
>> 
>> -Marshall
>> 
>> 
>> 
>> On 8/18/2017 8:55 AM, Andrew Trice wrote:
>>> I am working with UIMA-Alpha02 and am currently trying to build a jar to 
>>> make a standalone application. (not pear because we want our users to have 
>>> just the JDK and not require ecilpse or UIMA) In many cases we use maven to 
>>> build and package the jar and it runs fine. Other times the jar is broken 
>>> so that the pipeline will always fail with this stacktrace:
>>>  2017-08-17 14:53:54 [ERROR] DeidRunnerController.203: Throwing
>>> java.lang.ExceptionInInitializerError: null
>>> at 
>>> com.clinacuity.deid.ae.FileSystemCollectionReader.getNext(FileSystemCollectionReader.java:105)
>>>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> at com.clinacuity.deid.ae.DeidPipeline.execute(DeidPipeline.java:109) 
>>> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> at 
>>> com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:41) 
>>> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> at 
>>> com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:9) 
>>> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> at javafx.concurrent.Task$TaskCallable.call(Task.java:1423) 
>>> ~[jfxrt.jar:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
>>> ~[?:1.8.0_121]
>>> at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_121]
>>> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field 
>>> "documentType" is being initialized by non-framework (user) code before 
>>> Type System Commit for a type system with a corresponding type. Either 
>>> change the user load code to not do initialize, or to defer it until after 
>>> the type system commit.
>>> at 
>>> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2564)
>>>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> at 
>>> com.clinacuity.deid.annotations.DocumentInformationAnnotation.(DocumentInformationAnnotation.java:23)
>>>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>>> ... 7 more
>>> 
>>> I logged the JCas type system before this error occurs with this command: 
>>> jCas.getTypeSystem(), when it *passes* it shows the type system as this:
>>> 
>>> TypeSystem: Type System <2,016,464,189>:
>>>   uima.cas.TOP: super: 
>>> uima.cas.Integer: super: uima.cas.TOP
>>> uima.cas.Float: super: uima.cas.TOP
>>> uima.cas.String: super: uima.cas.TOP
>>> uima.cas.ArrayBase: super: uima.cas.TOP
>>> uima.cas.ListBase: super: uima.cas.TOP
>>> uima.cas.Boolean: super: uima.cas.TOP
>>> uima.cas.Byte: super: uima.cas.TOP
>>> uima.cas.Short: super: uima.cas.TOP
>>> uima.cas.Long: super: uima.cas.TOP
>>> uima.cas.Double: super: uima.cas.TOP
>>> uima.cas.Sofa: 

Re: Type system commit race condition when maven builds jar(?)

[Jean-Karlo Accetta]

Hi Marshall,

I work with Andrew. Thanks for the reply, this definitely helps!

Best regards,
J.K. Accetta



On 8/23/17 8:50 AM, Marshall Schor wrote:

Hi,

Those two listing of the type system appear to show that the *working* version
does not have cTakes, and the *failing* version has cTakes.

Any ideas why this might be so?

The stack trace appears to show that the "FileSystemCollectionReader" class is
running the getNext method, and that is attempting to create an instance of the
JCas class   com.clinacuity.deid.annotations.DocumentInformationAnnotation.

The error message indicates that whatever causes the class
com.clinacuity.deid.annotations.DocumentInformationAnnotation to be "loaded" &
"initialized" by Java's class loader is happening before the type system has
been committed.

It seems that the FileSystemCollectionReader is being run in some separate
thread.  If your system design is permitting this to happen in a race with
another thread which is setting up the type system and committing it, you could
get this error.  The fact that a big type system might take longer to set up
might account for why that one fails (the shorter one wins the race).

Of course, for reliable operation, the race must be eliminated; a fix would be
to delay starting threads that depend on the type system, until the type system
has been committed.

Does this help?

-Marshall



On 8/18/2017 8:55 AM, Andrew Trice wrote:

I am working with UIMA-Alpha02 and am currently trying to build a jar to make a 
standalone application. (not pear because we want our users to have just the 
JDK and not require ecilpse or UIMA) In many cases we use maven to build and 
package the jar and it runs fine. Other times the jar is broken so that the 
pipeline will always fail with this stacktrace:
  
2017-08-17 14:53:54 [ERROR] DeidRunnerController.203: Throwing

java.lang.ExceptionInInitializerError: null
at 
com.clinacuity.deid.ae.FileSystemCollectionReader.getNext(FileSystemCollectionReader.java:105)
 ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at com.clinacuity.deid.ae.DeidPipeline.execute(DeidPipeline.java:109) 
~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at 
com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:41) 
~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at 
com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:9) 
~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at javafx.concurrent.Task$TaskCallable.call(Task.java:1423) 
~[jfxrt.jar:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
~[?:1.8.0_121]
at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_121]
Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field 
"documentType" is being initialized by non-framework (user) code before Type 
System Commit for a type system with a corresponding type. Either change the user load 
code to not do initialize, or to defer it until after the type system commit.
at 
org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2564)
 ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at 
com.clinacuity.deid.annotations.DocumentInformationAnnotation.(DocumentInformationAnnotation.java:23)
 ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
... 7 more

I logged the JCas type system before this error occurs with this command: 
jCas.getTypeSystem(), when it *passes* it shows the type system as this:

TypeSystem: Type System <2,016,464,189>:
   uima.cas.TOP: super: 
 uima.cas.Integer: super: uima.cas.TOP
 uima.cas.Float: super: uima.cas.TOP
 uima.cas.String: super: uima.cas.TOP
 uima.cas.ArrayBase: super: uima.cas.TOP
 uima.cas.ListBase: super: uima.cas.TOP
 uima.cas.Boolean: super: uima.cas.TOP
 uima.cas.Byte: super: uima.cas.TOP
 uima.cas.Short: super: uima.cas.TOP
 uima.cas.Long: super: uima.cas.TOP
 uima.cas.Double: super: uima.cas.TOP
 uima.cas.Sofa: super: uima.cas.TOP, FeaturesIntroduced/Range/multiRef: [
   sofaNum/uima.cas.Integer/F,
   sofaID/uima.cas.String/F,
   mimeType/uima.cas.String/F,
   sofaArray/uima.cas.TOP/T,
   sofaString/uima.cas.String/F,
   sofaURI/uima.cas.String/F]
 uima.cas.AnnotationBase: super: uima.cas.TOP, 
FeaturesIntroduced/Range/multiRef: [
   sofa/uima.cas.Sofa/F]
 com.clinacuity.deid.uima.core.type.Lemma: super: uima.cas.TOP, 
FeaturesIntroduced/Range/multiRef: [
   key/uima.cas.String/F,
   posTag/uima.cas.String/F]
 com.clinacuity.deid.uima.core.type.OntologyConcept: super: uima.cas.TOP, 
FeaturesIntroduced/Range/multiRef: [
   codingScheme/uima.cas.String/F,
   code/uima.cas.String/F,
   oid/uima.cas.String/F]

but when it *fails* I get this:

TypeSystem: Type System <815,926,310>:
   uima.cas.TOP: super: 
 uima.cas.Integer: super: uima.cas.TOP
 uima.cas.Float: super: uima.cas.TOP
 uima.cas.String: super: 

Re: Type system commit race condition when maven builds jar(?)

[Marshall Schor]

Hi,

Those two listing of the type system appear to show that the *working* version
does not have cTakes, and the *failing* version has cTakes.

Any ideas why this might be so?

The stack trace appears to show that the "FileSystemCollectionReader" class is
running the getNext method, and that is attempting to create an instance of the
JCas class   com.clinacuity.deid.annotations.DocumentInformationAnnotation.

The error message indicates that whatever causes the class
com.clinacuity.deid.annotations.DocumentInformationAnnotation to be "loaded" &
"initialized" by Java's class loader is happening before the type system has
been committed.

It seems that the FileSystemCollectionReader is being run in some separate
thread.  If your system design is permitting this to happen in a race with
another thread which is setting up the type system and committing it, you could
get this error.  The fact that a big type system might take longer to set up
might account for why that one fails (the shorter one wins the race).

Of course, for reliable operation, the race must be eliminated; a fix would be
to delay starting threads that depend on the type system, until the type system
has been committed.

Does this help?

-Marshall



On 8/18/2017 8:55 AM, Andrew Trice wrote:
> I am working with UIMA-Alpha02 and am currently trying to build a jar to make 
> a standalone application. (not pear because we want our users to have just 
> the JDK and not require ecilpse or UIMA) In many cases we use maven to build 
> and package the jar and it runs fine. Other times the jar is broken so that 
> the pipeline will always fail with this stacktrace:
>  
> 2017-08-17 14:53:54 [ERROR] DeidRunnerController.203: Throwing
> java.lang.ExceptionInInitializerError: null
>   at 
> com.clinacuity.deid.ae.FileSystemCollectionReader.getNext(FileSystemCollectionReader.java:105)
>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   at com.clinacuity.deid.ae.DeidPipeline.execute(DeidPipeline.java:109) 
> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   at 
> com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:41) 
> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   at 
> com.clinacuity.deid.gui.DeidPipelineTask.call(DeidPipelineTask.java:9) 
> ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   at javafx.concurrent.Task$TaskCallable.call(Task.java:1423) 
> ~[jfxrt.jar:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_121]
>   at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_121]
> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field 
> "documentType" is being initialized by non-framework (user) code before Type 
> System Commit for a type system with a corresponding type. Either change the 
> user load code to not do initialize, or to defer it until after the type 
> system commit.
>   at 
> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2564)
>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   at 
> com.clinacuity.deid.annotations.DocumentInformationAnnotation.(DocumentInformationAnnotation.java:23)
>  ~[deid-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
>   ... 7 more
>
> I logged the JCas type system before this error occurs with this command: 
> jCas.getTypeSystem(), when it *passes* it shows the type system as this:
>
> TypeSystem: Type System <2,016,464,189>:
>   uima.cas.TOP: super: 
> uima.cas.Integer: super: uima.cas.TOP
> uima.cas.Float: super: uima.cas.TOP
> uima.cas.String: super: uima.cas.TOP
> uima.cas.ArrayBase: super: uima.cas.TOP
> uima.cas.ListBase: super: uima.cas.TOP
> uima.cas.Boolean: super: uima.cas.TOP
> uima.cas.Byte: super: uima.cas.TOP
> uima.cas.Short: super: uima.cas.TOP
> uima.cas.Long: super: uima.cas.TOP
> uima.cas.Double: super: uima.cas.TOP
> uima.cas.Sofa: super: uima.cas.TOP, FeaturesIntroduced/Range/multiRef: [
>   sofaNum/uima.cas.Integer/F, 
>   sofaID/uima.cas.String/F, 
>   mimeType/uima.cas.String/F, 
>   sofaArray/uima.cas.TOP/T, 
>   sofaString/uima.cas.String/F, 
>   sofaURI/uima.cas.String/F]
> uima.cas.AnnotationBase: super: uima.cas.TOP, 
> FeaturesIntroduced/Range/multiRef: [
>   sofa/uima.cas.Sofa/F]
> com.clinacuity.deid.uima.core.type.Lemma: super: uima.cas.TOP, 
> FeaturesIntroduced/Range/multiRef: [
>   key/uima.cas.String/F, 
>   posTag/uima.cas.String/F]
> com.clinacuity.deid.uima.core.type.OntologyConcept: super: uima.cas.TOP, 
> FeaturesIntroduced/Range/multiRef: [
>   codingScheme/uima.cas.String/F, 
>   code/uima.cas.String/F, 
>   oid/uima.cas.String/F]
>
> but when it *fails* I get this:
>
> TypeSystem: Type System <815,926,310>:
>   uima.cas.TOP: super: 
> uima.cas.Integer: super: uima.cas.TOP
> uima.cas.Float: super: uima.cas.TOP
> uima.cas.String: super: uima.cas.TOP
> uima.cas.ArrayBase: super: