Re: [jira] [Created] (UIMA-5694) UIMA-AS: Update README to say that mvn -U should be used for building

[Marshall Schor]

Normal builds with good network connectivity shouldn't need to use the -U 
operation.

doing the -U operator makes building much slower. That's why it's usually not
done; but only done when the build needs to depend on something whose "access"
path to the artifact in the cloud "failed" - to prevent excess network delays,
these are blocked for 1 day (but the -U overrides that).

see https://www.google.com/search?q=maven+%22-u%22

-Marshall
On 1/5/2018 4:30 PM, Jerry Cwiklik (JIRA) wrote:
> Jerry Cwiklik created UIMA-5694:
> ---
>
>  Summary: UIMA-AS: Update README to say that mvn -U should be 
> used for building
>  Key: UIMA-5694
>  URL: https://issues.apache.org/jira/browse/UIMA-5694
>  Project: UIMA
>   Issue Type: Improvement
>   Components: Async Scaleout
> Reporter: Jerry Cwiklik
> Assignee: Jerry Cwiklik
>  Fix For: future-Uima-AS
>
>
> The local m2 repo may get stale and builds may fail with strange errors like 
> this:
> [ERROR] Failed to execute goal on project uimaj-ep-deployeditor: Could not 
> resolve dependencies for project 
> org.apache.uima:uimaj-ep-deployeditor:jar:2.10.2: Failed to collect 
> dependencies at org.eclipse.pde:org.eclipse.pde.ui:jar:3.9.100 -> 
> org.eclipse.pde:org.eclipse.pde.core:jar:[3.6.0,4.0.0): No versions available 
> for org.eclipse.pde:org.eclipse.pde.core:jar:[3.6.0,4.0.0) within specified 
> range -> [Help 1] 
>
> When building force maven to check for updated releases and snapshots on 
> remote repositories using this command:
>
> mvn -U clean install
>
> Note the -U which forces the update.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Marshall Schor]

I perhaps overstated the problem.

Here's the specifics:  if the maximal-type system for type T has features f1,
f2, f3, f4, f5, and the JCas class defines all these features, then the load of
that JCas class will bind those.

A subsequent switch to a type system with f1, f2, will work.

But a subsequent switch to a type system with f1, f3 won't work (because the
offset for f3 is set to, say "3", and the length of the feature slots allocated
is only 2.

To work around these, the application needs to use class loader isolation to
force reloading of the JCas classes.
(Or, as mentioned earlier, we could have an API to recalculate the offsets, but
that could really break things if instances of that JCas class exist (perhaps
running in other threads) expecting the other definitions.

So I think any client code doing type system switching, and using JCas classes
where the features are changing, needs to be aware and handle this (currently).

A fix along the lines suggested where the JCas classes augment the type system,
could help, but it would still be exposed to edge cases like this:

TypeSystem 1 defines type T with f1; JCas augments this with f100.

Later a typesystem is loaded which defines types f1, f2, and f100 (in that
order). The JCas for T has bound f100 to (say) slot #2, which is where this type
system has stuck "f2" - so it has the wrong binding for f100.

-Marshall


On 1/5/2018 4:25 PM, Richard Eckart de Castilho wrote:
> On 05.01.2018, at 21:29, Marshall Schor  wrote:
>> So, the only work-around I see at the moment is to use class loader 
>> isolation,
>> reloading the JCas classes each time.
> Is this something that client code would have to be aware of / to trigger?
>
> Cheers,
>
> -- Richard

[jira] [Created] (UIMA-5694) UIMA-AS: Update README to say that mvn -U should be used for building

[Jerry Cwiklik (JIRA)]

Jerry Cwiklik created UIMA-5694:
---

 Summary: UIMA-AS: Update README to say that mvn -U should be used 
for building
 Key: UIMA-5694
 URL: https://issues.apache.org/jira/browse/UIMA-5694
 Project: UIMA
  Issue Type: Improvement
  Components: Async Scaleout
Reporter: Jerry Cwiklik
Assignee: Jerry Cwiklik
 Fix For: future-Uima-AS


The local m2 repo may get stale and builds may fail with strange errors like 
this:
[ERROR] Failed to execute goal on project uimaj-ep-deployeditor: Could not 
resolve dependencies for project 
org.apache.uima:uimaj-ep-deployeditor:jar:2.10.2: Failed to collect 
dependencies at org.eclipse.pde:org.eclipse.pde.ui:jar:3.9.100 -> 
org.eclipse.pde:org.eclipse.pde.core:jar:[3.6.0,4.0.0): No versions available 
for org.eclipse.pde:org.eclipse.pde.core:jar:[3.6.0,4.0.0) within specified 
range -> [Help 1] 

When building force maven to check for updated releases and snapshots on remote 
repositories using this command:

mvn -U clean install

Note the -U which forces the update.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Richard Eckart de Castilho]

On 05.01.2018, at 21:29, Marshall Schor  wrote:
> 
> So, the only work-around I see at the moment is to use class loader isolation,
> reloading the JCas classes each time.

Is this something that client code would have to be aware of / to trigger?

Cheers,

-- Richard

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Marshall Schor]

Hi Richard,

This sounds like an interesting idea - to have the JCas classes (perhaps
augmented with some annotations) serve as additional type definitions.

I believe that the current implementation won't work even if the maximal-feature
definition was loaded first.  This is because the offsets would be computed for
that definition, and then when a subsequent type system was loaded (with fewer
features), the feature offsets would remain the same (for the maximal Features)
but the arrays they would be indexing into would be smaller (the size of the
loaded type system).

So, the only work-around I see at the moment is to use class loader isolation,
reloading the JCas classes each time. 

I'll look more into how to design the a fix around your idea (merging the JCas
imputed type info).

Cheers. -Marshall


On 1/5/2018 2:05 PM, Richard Eckart de Castilho wrote:
> On 05.01.2018, at 17:16, Marshall Schor  wrote:
>> Based on Web Annot's use case, I'm thinking thorough alternatives.
> "WebAnno" ;)
>
>> One way to support this would be to have the user code tell the UIMA 
>> framework
>> that no reachable instances of JCas classes exist; the user would be 
>> responsible
>> for guaranteeing this.
> There may be no way for the user code to know if this is the case or not or 
> to 
> enforce this to be the case. 
>
>> The other choice would be to not support this (because of the inherent 
>> dangers)
>> and instead require users having multiple type systems with JCas classes
>> specifying features only in some versions of those type systems, first load 
>> the
>> JCas classes with the feature-maximal versions of the types.
>>
>> I think I favor the 2nd approach, as it is much safer. 
>>
>> What do others think we should do?
> The current line of thinking seems to assume that:
>
> 1) a type system definition is loaded (maybe from an XML file)
> 2) a CAS is created using the TSD
> 3) the JCas classes are loaded and are initialized according to the TSD
>
> The suggestion to "first load a feature-maximal version of the types" seems
> to be following that line. I.e. the TSD loaded in 1) should cover all
> the features also covered by the JCas classes.
>
> How about a slightly different approach:
>
> 1) a type system definition is loaded (maybe from an XML file)
> 1a) the JCas classes are loaded and their definitions are merged with the
> TSD
> 2) a CAS is created using the merged TSD
> 3) the JCas classes are initialized with the now feature-maximal type system
>
> An error would/should be thrown if in step 1a the JCas classes
> and the TSD are inherently incompatible. 
>
> In this case, the JCas classes would be an additional source of type system
> information. Thinking this further, one could even initialize a CAS without
> providing any TSD, simply by having UIMA inspect the available JCas classes
> (e.g. through classpath scanning or by providing the framework with a list
> of classes). To complete this, the JCas classes could be enhanced with
> Java annotations to carry any information included in TSDs which is currently
> not included in a machine-readable way in the JCas classes, e.g. type and
> feature description text. As such, a set of suitably annotated JCas classes
> could be converted to a TSD XML and vice versa.
>
> The above assumes that JCas classes are loaded and initialized eagerly, but 
> probably it could be adapted to a situation where the classes are loaded 
> lazily.
>
> Cheers,
>
> -- Richard
>
>

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Richard Eckart de Castilho]

On 05.01.2018, at 17:16, Marshall Schor  wrote:
> 
> Based on Web Annot's use case, I'm thinking thorough alternatives.

"WebAnno" ;)

> One way to support this would be to have the user code tell the UIMA framework
> that no reachable instances of JCas classes exist; the user would be 
> responsible
> for guaranteeing this.

There may be no way for the user code to know if this is the case or not or to 
enforce this to be the case. 

> The other choice would be to not support this (because of the inherent 
> dangers)
> and instead require users having multiple type systems with JCas classes
> specifying features only in some versions of those type systems, first load 
> the
> JCas classes with the feature-maximal versions of the types.
> 
> I think I favor the 2nd approach, as it is much safer. 
> 
> What do others think we should do?

The current line of thinking seems to assume that:

1) a type system definition is loaded (maybe from an XML file)
2) a CAS is created using the TSD
3) the JCas classes are loaded and are initialized according to the TSD

The suggestion to "first load a feature-maximal version of the types" seems
to be following that line. I.e. the TSD loaded in 1) should cover all
the features also covered by the JCas classes.

How about a slightly different approach:

1) a type system definition is loaded (maybe from an XML file)
1a) the JCas classes are loaded and their definitions are merged with the
TSD
2) a CAS is created using the merged TSD
3) the JCas classes are initialized with the now feature-maximal type system

An error would/should be thrown if in step 1a the JCas classes
and the TSD are inherently incompatible. 

In this case, the JCas classes would be an additional source of type system
information. Thinking this further, one could even initialize a CAS without
providing any TSD, simply by having UIMA inspect the available JCas classes
(e.g. through classpath scanning or by providing the framework with a list
of classes). To complete this, the JCas classes could be enhanced with
Java annotations to carry any information included in TSDs which is currently
not included in a machine-readable way in the JCas classes, e.g. type and
feature description text. As such, a set of suitably annotated JCas classes
could be converted to a TSD XML and vice versa.

The above assumes that JCas classes are loaded and initialized eagerly, but 
probably it could be adapted to a situation where the classes are loaded lazily.

Cheers,

-- Richard

Re: UIMAv3 & WebAnno

[Richard Eckart de Castilho]

Hi,

> On 04.01.2018, at 22:18, Marshall Schor  wrote:
> 
> Hi Richard,
> 
> Here's one idea:  Since I thought this had been fixed a while ago, and you
> seemed (previously) to get beyond this point, I'm wondering if the build you 
> dd
> for "trunk" somehow got mixed up levels.  I see the build is from
> 3.0.1-beta-SNAPSHOT v3 branch - but I'm guessing that's some local folder you
> have ( didn't see it in
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/branches)?

I built from https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/trunk
which has the version "3.0.1-beta-SNAPSHOT" in the pom.xml.

> I'm going to try to set up a test case to see if I can reproduce this.  What 
> I'm
> planning to do is to have two type systems, T1, and T2, where T1 has a type 
> with
> no features, and T2 has the same type with a feature.
> 
> I'll make a JCas class which has the type defined with the feature.
> 
> Then I'll create a CAS with T1, and confirm the JCas class loads and has the
> feature offset for the feature set to -1 (to cause a runtime exception if
> referenced).
> 
> Then I'll create a CAS with T2.  If this test case matches what's happening 
> for
> you, that should trigger the exception you see.

That sounds like it should be able to reproduce the problem.

I could imagine this issue to appear in scenarios where JCas classes exist
and CASes with (slightly) different type systems are deserialized from disk
and the type system of the in-memory CAS is reinitialized from the file
stored on disk - so not necessarily a problem limited to WebAnno.

From my perspective as a UIMA v2 user, the JCas classes are a convenience that
allows for type-safe access to the CAS. But at least in v2, it seems to be 
absolutely possible to use JCas classes even with CASes that have been 
initialized with a slightly different type system, i.e. with more or less
features than the JCas class actually offers. In case there are more features,
I can always access them through the CAS API. In case there are less features,
then the getters/setters in the JCas class for these features would fail - but
only when I actually try to call them. I think at some point, UIMAv2 started to 
log
warnings if a JCas class had getters/setters for features that were not actually
present in the type system...

> JCas Type "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Token" 
> implements getters and setters for feature "morph", but the type system 
> doesn't define that feature.


... but other than that, everything still worked fine since I didn't actually 
access
these features - and if they would be accessed, they would also have been added
to the type system in the respective CAS before.

So to summarize - in the UIMAv2 environment that WebAnno creates, we have:

- one set of JCas classes that usually partially overlaps with the 
types/features
  with which the CASes are initialized
- at any time, any number of CAS instances, potentially each with a different
  type system may exist in memory
- a particular CAS instance is (usually) accessed only from a single thread
  (this might change soon as asynchronous events are being introduced)
- for some types/features, the JCas classes are used for access, for other
  types/features the CAS API is used
- when a CAS is passed around, it is usually passed around as a JCas object
  and jcas.getCas() is called when the CAS API should be used

Now, on the other hand, one might argue that this "wild" mixing of JCas classes
with type systems deviating from the one from which the JCas classes were 
originally
created is a bad practice. Personally, I found it convenient because at least 
for
some types/features, I could use a convenient Java-like type safe access. The
alternative would be to completely stop using JCas (at least in WebAnno) and 
work
only via the CAS API.

I could try to do a workaround that creates a CAS at application startup with 
the
type system from which the JCas classes were built in order to initialize the 
JCas
class registry. But no idea if that would fix the issue / whether I would have 
to
do that on every thread that is spawned or if it would be sufficient to do it 
once
on any arbitrary thread... it doesn't sound like a particularly attractive 
solution
though.

Cheers,

-- Richard

[jira] [Updated] (UIMA-5656) uv3 consider enabling Java 9

[Marshall Schor (JIRA)]

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

Marshall Schor updated UIMA-5656:
-
Fix Version/s: (was: 3.0.0SDK)

> uv3 consider enabling Java 9
> 
>
> Key: UIMA-5656
> URL: https://issues.apache.org/jira/browse/UIMA-5656
> Project: UIMA
>  Issue Type: Improvement
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Assignee: Marshall Schor
>Priority: Minor
>
> Investigate and see what's needed to enable running with Java 9.
> Modify code to make future use of Java 9 better. 
> Continue to run with Java 8
> A main thing to do now it to make automatic naming of Jars have appropriate 
> names.  See 
> http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] UIMA-AS 2.10.2 RC5

[Jaroslaw Cwiklik]

Just to make this more clear, Eddie and I together determined that the AMQ
connection losses where due to
long GCs in the service. This conclusion was based on evidence found in the
service log and correlation with
jConsole stats.

Jerry

On Fri, Jan 5, 2018 at 10:56 AM, Jaroslaw Cwiklik 
wrote:

> After reviewing the service log and looking at jConsole there are long GCs
> which cause connection loss and recovery.
> Looks like AE issue. Strange that these GCs happen if the service is idle.
> Someone should profile this AE to confirm
> where this and possibly fix the source of excessive garbage.
>
> Another possibility is to increase AMQ inactivityTimeout (default 30 secs)
> to prevent connection drops.
>
> Jerry
>
> On Tue, Jan 2, 2018 at 11:16 AM, Eddie Epstein 
> wrote:
>
>> There were no long GCs for this service. Note (from above) that many other
>> services running older versions of uima-as were also showing the same
>> behavior.
>>
>> Eddie
>>
>> On Tue, Jan 2, 2018 at 9:21 AM, Jaroslaw Cwiklik 
>> wrote:
>>
>> > Looks like the client lost connection to the broker for some reason.
>> Long
>> > GC perhaps? But eventually the service should have recovered. Any
>> > indication of connection
>> > recovery later?
>> >
>> > Jerry
>> >
>> > On Sun, Dec 24, 2017 at 11:34 AM, Eddie Epstein 
>> > wrote:
>> >
>> > > Jerry,
>> > >
>> > > Testing a real analytic running 28 sync pipelines as a DUCC managed
>> > UIMA-AS
>> > > service, the DUCC pinger is reporting failures for an idle service 2
>> or 3
>> > > times a day.
>> > >
>> > > sm.log, an error surrounded by good pings, the ping normally done
>> every 2
>> > > minutes:
>> > >
>> > > Dec 2017 07:49:42,740  INFO SM.PingDriver - 10668 T[3588945]
>> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
>> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3] Prod[1]
>> > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
>> > > MetaNode[192.168.7.101] MetaPid[71061:91]
>> > > Dec 2017 07:51:42,844  INFO SM.PingDriver - 10668 T[3588945]
>> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
>> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3] Prod[1]
>> > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
>> > > MetaNode[192.168.7.101] MetaPid[71061:91]
>> > > Dec 2017 07:54:02,912 ERROR SM.PingDriver - 10668 T[3588945]
>> > > handleStatistics  Missed_pings  1 endpoint
>> > > UIMA-AS:eae-r1.16:tcp://broker1:61616 Alive[false] Healthy[false] +
>> > Info:
>> > > QDEPTH[0] AveNQ[0] Consum[3] Prod[1] minNQ[0] maxNQ[0] expCnt[0]
>> inFlt[0]
>> > > DQ[1] NQ[1] NDisp[1] MetaNode[N/A] MetaPid[N/A]: Cannot issue getMeta
>> to:
>> > > eae-r1.16:tcp://broker1:61616: java.util.concurrent.TimeoutException
>> > > Dec 2017 07:56:03,016  INFO SM.PingDriver - 10668 T[3588945]
>> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
>> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[89570] Consum[3]
>> > Prod[1]
>> > > minNQ[89570] maxNQ[89570] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
>> > > MetaNode[192.168.7.101] MetaPid[71061:91]
>> > >
>> > > The broker logfile, complaining about all three service listeners
>> around
>> > > the same time (the service runs on 192.168.7.101):
>> > >
>> > > 2017-12-24 07:54:48,257 [yMonitor Worker] WARN  Transport
>> > > - Transport Connection to: tcp://192.168.7.101:43895 failed:
>> > > org.apache.activemq.transport.InactivityIOException: Channel was
>> > inactive
>> > > for too (>3) long: tcp://192.168.7.101:43895
>> > > 2017-12-24 07:54:48,287 [yMonitor Worker] WARN  Transport
>> > > - Transport Connection to: tcp://192.168.7.101:43898 failed:
>> > > org.apache.activemq.transport.InactivityIOException: Channel was
>> > inactive
>> > > for too (>3) long: tcp://192.168.7.101:43898
>> > > 2017-12-24 07:54:48,288 [yMonitor Worker] WARN  Transport
>> > > - Transport Connection to: tcp://192.168.7.101:43899 failed:
>> > > org.apache.activemq.transport.InactivityIOException: Channel was
>> > inactive
>> > > for too (>3) long: tcp://192.168.7.101:43899
>> > >
>> > > The service logfile also reporting problems for all three listeners:
>> > >
>> > > 07:55:12.457 - 91:
>> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
>> > > ainer.onException:
>> > > WARNING: Service: Processing2 Runtime Exception
>> > > 07:55:12.457 - 91:
>> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
>> > > ainer.onException:
>> > > WARNING: Jms Listener Failed. Endpoint: eae-r1.16 Managed By:
>> > > tcp://broker1:61616 Reason: javax.jms.JMSException:
>> java.io.EOFException
>> > > 07:55:12.457 - 91:
>> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
>> > ainer.
>> > > handleListenerSetupFailure:
>> > > WARNING: Uima AS Service:Processing2 Listener Unable To Connect To
>> > Broker:
>> > > 

Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Marshall Schor]

Based on Web Annot's use case, I'm thinking thorough alternatives.

The issue is a sequence related one, with type systems changing:

1) a type system is created, defining type T, with no features
2) a CAS is produced with that type system, causing JCas classes to be looked-up
and loaded

At that time, the JCas class is set up with feature offset constants,
corresponding to how the features are laid out in the type system.
Type T has 0 features, but the JCas type for T might define some.  This is
allowed, but the feature offsets in the JCas class are set to -1, which will
cause a runtime exception if the feature is used (e.g., someone does
myJCasType.getMyFeature() call).

So far - all OK (provided the non-existent features are not accessed, of 
course).

3) a different type system is created, defining type T with feature f1
4) a CAS is produced with that type system.

Currently this throws an error when the JCas classes are checked for conformance
with the type system. 

A mechanism in the JCas already allows the JCas classes to be "updated" for
feature changes.
However, once the JCas class is loaded with a valid type system, no updating is
allowed (for reasons see below).

The consequence of this is that a user wanting to use one set of JCas classes
with multiple different type systems must use the maximal-feature version of the
type systems (which could be created using a type system merge operation, for
example), as the *first* type system that causes the JCas classes to be loaded.

We could modify the JCas setup to allow updating an already loaded/initialized
JCas class for a new type system with different features present. But it seems
that this has some difficulties; it would only be a valid transformation if no
instances of the JCas class exist.  There's currently no way to tell if this is
true.  In the general case, the JCas classes could be being used for multiple
independent pipelines, running in multiple threads; so even if one CAS was
"reset", others might not be; and furthermore, POJO code could be holding on to
some JCas instances.

One way to support this would be to have the user code tell the UIMA framework
that no reachable instances of JCas classes exist; the user would be responsible
for guaranteeing this.

The other choice would be to not support this (because of the inherent dangers)
and instead require users having multiple type systems with JCas classes
specifying features only in some versions of those type systems, first load the
JCas classes with the feature-maximal versions of the types.

I think I favor the 2nd approach, as it is much safer. 

What do others think we should do?

-Marshall

Re: [VOTE] UIMA-AS 2.10.2 RC5

[Jaroslaw Cwiklik]

After reviewing the service log and looking at jConsole there are long GCs
which cause connection loss and recovery.
Looks like AE issue. Strange that these GCs happen if the service is idle.
Someone should profile this AE to confirm
where this and possibly fix the source of excessive garbage.

Another possibility is to increase AMQ inactivityTimeout (default 30 secs)
to prevent connection drops.

Jerry

On Tue, Jan 2, 2018 at 11:16 AM, Eddie Epstein  wrote:

> There were no long GCs for this service. Note (from above) that many other
> services running older versions of uima-as were also showing the same
> behavior.
>
> Eddie
>
> On Tue, Jan 2, 2018 at 9:21 AM, Jaroslaw Cwiklik 
> wrote:
>
> > Looks like the client lost connection to the broker for some reason. Long
> > GC perhaps? But eventually the service should have recovered. Any
> > indication of connection
> > recovery later?
> >
> > Jerry
> >
> > On Sun, Dec 24, 2017 at 11:34 AM, Eddie Epstein 
> > wrote:
> >
> > > Jerry,
> > >
> > > Testing a real analytic running 28 sync pipelines as a DUCC managed
> > UIMA-AS
> > > service, the DUCC pinger is reporting failures for an idle service 2
> or 3
> > > times a day.
> > >
> > > sm.log, an error surrounded by good pings, the ping normally done
> every 2
> > > minutes:
> > >
> > > Dec 2017 07:49:42,740  INFO SM.PingDriver - 10668 T[3588945]
> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3] Prod[1]
> > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > > Dec 2017 07:51:42,844  INFO SM.PingDriver - 10668 T[3588945]
> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3] Prod[1]
> > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > > Dec 2017 07:54:02,912 ERROR SM.PingDriver - 10668 T[3588945]
> > > handleStatistics  Missed_pings  1 endpoint
> > > UIMA-AS:eae-r1.16:tcp://broker1:61616 Alive[false] Healthy[false] +
> > Info:
> > > QDEPTH[0] AveNQ[0] Consum[3] Prod[1] minNQ[0] maxNQ[0] expCnt[0]
> inFlt[0]
> > > DQ[1] NQ[1] NDisp[1] MetaNode[N/A] MetaPid[N/A]: Cannot issue getMeta
> to:
> > > eae-r1.16:tcp://broker1:61616: java.util.concurrent.TimeoutException
> > > Dec 2017 07:56:03,016  INFO SM.PingDriver - 10668 T[3588945]
> > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[89570] Consum[3]
> > Prod[1]
> > > minNQ[89570] maxNQ[89570] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > >
> > > The broker logfile, complaining about all three service listeners
> around
> > > the same time (the service runs on 192.168.7.101):
> > >
> > > 2017-12-24 07:54:48,257 [yMonitor Worker] WARN  Transport
> > > - Transport Connection to: tcp://192.168.7.101:43895 failed:
> > > org.apache.activemq.transport.InactivityIOException: Channel was
> > inactive
> > > for too (>3) long: tcp://192.168.7.101:43895
> > > 2017-12-24 07:54:48,287 [yMonitor Worker] WARN  Transport
> > > - Transport Connection to: tcp://192.168.7.101:43898 failed:
> > > org.apache.activemq.transport.InactivityIOException: Channel was
> > inactive
> > > for too (>3) long: tcp://192.168.7.101:43898
> > > 2017-12-24 07:54:48,288 [yMonitor Worker] WARN  Transport
> > > - Transport Connection to: tcp://192.168.7.101:43899 failed:
> > > org.apache.activemq.transport.InactivityIOException: Channel was
> > inactive
> > > for too (>3) long: tcp://192.168.7.101:43899
> > >
> > > The service logfile also reporting problems for all three listeners:
> > >
> > > 07:55:12.457 - 91:
> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > ainer.onException:
> > > WARNING: Service: Processing2 Runtime Exception
> > > 07:55:12.457 - 91:
> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > ainer.onException:
> > > WARNING: Jms Listener Failed. Endpoint: eae-r1.16 Managed By:
> > > tcp://broker1:61616 Reason: javax.jms.JMSException:
> java.io.EOFException
> > > 07:55:12.457 - 91:
> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > ainer.
> > > handleListenerSetupFailure:
> > > WARNING: Uima AS Service:Processing2 Listener Unable To Connect To
> > Broker:
> > > tcp://broker1:61616 Retrying Until Successful ...
> > > 07:55:12.457 - 2336:
> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > ainer.onException:
> > > WARNING: Service: Processing2 Runtime Exception
> > > 07:55:12.457 - 2336:
> > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > ainer.onException:
> > > WARNING: Jms Listener Failed. Endpoint: eae-r1.16 Managed By:
> > > tcp://broker1:61616 

Re: UIMAv3 & WebAnno

[Marshall Schor]

I think I may have found the issue.

Working on a proper fix...

-Marshall

On 1/3/2018 6:16 PM, Richard Eckart de Castilho wrote:
> Hi again,
>
> I have once again switched my local environment to a UIMA v3 mode:
>
> - UIMA SDK v3 (3.0.1-beta-SNAPSHOT v3 branch)
> - uimaFIT (3.0.0-SNAPSHOT v3 branch)
> - DKPro Core (2.0.x branch)
> - WebAnno (feature/issue1115-uimav3 branch)
>
> Last time, I ran into trouble because the IDs loaded from serialized CAS 
> files were no longer accessible.
> I programmatically set "uima.default_v2_id_references" to "true" during 
> startup now to avoid that.
>
>
> But what seems to be happening even before getting there is that I run again 
> in JCas <-> Type System problems.
> When a user opens a document for annotation in WebAnno, WebAnno loads the 
> serialized CAS (CasCompleteSerializer),
> serializes the CAS into a byte array (compressed form 6), creates a new CAS 
> with the current type system definition,
> and deserializes the data again into that CAS. The idea is that the lenient 
> loading of the compressed form 6 allows
>
>   a) new types / features to be added in that way
>   b) unreachable FSes to be garbage collected
>
> So, it is not an uncommon case here that the data stored with the 
> CasCompleteSerializer used a different type system than the CAs into which it 
> is loaded - and in fact it can be the case that the data stored with the 
> CasCompleteSerializer had used different JCas wrappers at the time then what 
> is available at the time of loading
> the data again. Afaik in there should be no truely incompatible changes in 
> the type system though - i.e. only new features / types were added; no 
> features were removed. Still, I get a lot of this type of error:
>
>> org.apache.uima.cas.CASRuntimeException: The JCas cannot be initialized.  
>> The following errors occurred: 
>> In JCAS class 
>> "de.tudarmstadt.ukp.dkpro.core.api.lexmorph.type.morph.MorphologicalFeatures",
>>  UIMA field 
>> "de.tudarmstadt.ukp.dkpro.core.api.lexmorph.type.morph.MorphologicalFeatures:verbForm"
>>  was set up when this class was previously loaded and initialized, to have 
>> an adjusted offset of "-1" but now the feature has a different adjusted 
>> offset of "5"; this may be due to something else other than type system 
>> commit actions loading and initializing the JCas class, or to having a 
>> different non-compatible type system for this class, trying to use a common 
>> JCas cover class, which is not supported. 
>>  
>>  at 
>> org.apache.uima.cas.impl.FSClassRegistry.reportErrors(FSClassRegistry.java:870)
>>  ~[classes/:?]
>>  at 
>> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:342)
>>  ~[classes/:?]
>>  at 
>> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:904)
>>  ~[classes/:?]
>>  at 
>> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2651)
>>  ~[classes/:?]
>>  at 
>> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1393) 
>> ~[classes/:?]
>>  at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1607) 
>> ~[classes/:?]
>>  at 
>> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:614) 
>> ~[classes/:?]
>>  at 
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362) 
>> ~[classes/:?]
>>  at 
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313) 
>> ~[classes/:?]
>>  at 
>> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:147) 
>> ~[classes/:?]
>>  at 
>> de.tudarmstadt.ukp.clarin.webanno.api.dao.AnnotationSchemaServiceImpl.upgradeCas(AnnotationSchemaServiceImpl.java:640)
>>  ~[classes/:?]
> I have the feeling that this is what happens:
>
> 1) a CasCompleteSerialized-CAS is loaded - it was created at a time when the 
> MorphologicalFeatures did not yet have a feature called "verbForm".
> 2) I create a new JCas, now using a type system description where 
> MorphologicalFeatures includes the "verbForm" feature
>
> At step 2, the above error seems to be triggered. I actually do not even get 
> to the point where I would temporarily serialize into form 6 and back. The 
> code already crashes when trying to set up the target task with the updated 
> type system.
>
> Any ideas?
>
> Cheers,
>
> -- Richard

Re: [VOTE] UIMA-AS 2.10.2 RC5

[Burn Lewis]

- Checked signatures - OK
- Tested binary with a dozen CASes - OK
- Built from source & checked signatures - OK
- Tested source build with a dozen CASes - OK
- Spot checked README, RELEASE_NOTES, LICENSE, NOTICE, JIRAs, docs - OK
- Tested TargetServiceId - OK

 Minor complaint - The (undocumented) -TargetServiceId option on
RunRemoteAsyncAE does not send a targeted CAS.

[ ] +1 OK to release

~Burn

On Tue, Jan 2, 2018 at 11:21 AM, Jaroslaw Cwiklik 
wrote:

> "Many other" = "all services " were kaput? If so, it could be the broker
> failure (what version?) or something else. Sorry cant pinpoint this stuff
> with accuracy since the broken connection can be symptom of many problems.
> Is this system in the kaput state still?
>
> Jerry
>
> On Tue, Jan 2, 2018 at 11:16 AM, Eddie Epstein 
> wrote:
>
> > There were no long GCs for this service. Note (from above) that many
> other
> > services running older versions of uima-as were also showing the same
> > behavior.
> >
> > Eddie
> >
> > On Tue, Jan 2, 2018 at 9:21 AM, Jaroslaw Cwiklik 
> > wrote:
> >
> > > Looks like the client lost connection to the broker for some reason.
> Long
> > > GC perhaps? But eventually the service should have recovered. Any
> > > indication of connection
> > > recovery later?
> > >
> > > Jerry
> > >
> > > On Sun, Dec 24, 2017 at 11:34 AM, Eddie Epstein 
> > > wrote:
> > >
> > > > Jerry,
> > > >
> > > > Testing a real analytic running 28 sync pipelines as a DUCC managed
> > > UIMA-AS
> > > > service, the DUCC pinger is reporting failures for an idle service 2
> > or 3
> > > > times a day.
> > > >
> > > > sm.log, an error surrounded by good pings, the ping normally done
> > every 2
> > > > minutes:
> > > >
> > > > Dec 2017 07:49:42,740  INFO SM.PingDriver - 10668 T[3588945]
> > > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3]
> Prod[1]
> > > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > > > Dec 2017 07:51:42,844  INFO SM.PingDriver - 10668 T[3588945]
> > > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[0] Consum[3]
> Prod[1]
> > > > minNQ[0] maxNQ[0] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > > > Dec 2017 07:54:02,912 ERROR SM.PingDriver - 10668 T[3588945]
> > > > handleStatistics  Missed_pings  1 endpoint
> > > > UIMA-AS:eae-r1.16:tcp://broker1:61616 Alive[false] Healthy[false] +
> > > Info:
> > > > QDEPTH[0] AveNQ[0] Consum[3] Prod[1] minNQ[0] maxNQ[0] expCnt[0]
> > inFlt[0]
> > > > DQ[1] NQ[1] NDisp[1] MetaNode[N/A] MetaPid[N/A]: Cannot issue getMeta
> > to:
> > > > eae-r1.16:tcp://broker1:61616: java.util.concurrent.TimeoutException
> > > > Dec 2017 07:56:03,016  INFO SM.PingDriver - 10668 T[3588945]
> > > > handleStatistics  Ping ok:  UIMA-AS:eae-r1.16:tcp://broker1:61616
> > > > Alive[true] Healthy[true] + Info: QDEPTH[0] AveNQ[89570] Consum[3]
> > > Prod[1]
> > > > minNQ[89570] maxNQ[89570] expCnt[0] inFlt[0] DQ[1] NQ[1] NDisp[1]
> > > > MetaNode[192.168.7.101] MetaPid[71061:91]
> > > >
> > > > The broker logfile, complaining about all three service listeners
> > around
> > > > the same time (the service runs on 192.168.7.101):
> > > >
> > > > 2017-12-24 07:54:48,257 [yMonitor Worker] WARN  Transport
> > > > - Transport Connection to: tcp://192.168.7.101:43895 failed:
> > > > org.apache.activemq.transport.InactivityIOException: Channel was
> > > inactive
> > > > for too (>3) long: tcp://192.168.7.101:43895
> > > > 2017-12-24 07:54:48,287 [yMonitor Worker] WARN  Transport
> > > > - Transport Connection to: tcp://192.168.7.101:43898 failed:
> > > > org.apache.activemq.transport.InactivityIOException: Channel was
> > > inactive
> > > > for too (>3) long: tcp://192.168.7.101:43898
> > > > 2017-12-24 07:54:48,288 [yMonitor Worker] WARN  Transport
> > > > - Transport Connection to: tcp://192.168.7.101:43899 failed:
> > > > org.apache.activemq.transport.InactivityIOException: Channel was
> > > inactive
> > > > for too (>3) long: tcp://192.168.7.101:43899
> > > >
> > > > The service logfile also reporting problems for all three listeners:
> > > >
> > > > 07:55:12.457 - 91:
> > > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > > ainer.onException:
> > > > WARNING: Service: Processing2 Runtime Exception
> > > > 07:55:12.457 - 91:
> > > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > > ainer.onException:
> > > > WARNING: Jms Listener Failed. Endpoint: eae-r1.16 Managed By:
> > > > tcp://broker1:61616 Reason: javax.jms.JMSException:
> > java.io.EOFException
> > > > 07:55:12.457 - 91:
> > > > org.apache.uima.adapter.jms.activemq.UimaDefaultMessageListenerCont
> > > ainer.
> > > >