uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslaw Cwiklik <uim...@gmail.com>
Subject Re: UIMA-AS 2.4.0 - RunRemoteAsyncAE - destroy methods not called properly - JVM exits too early
Date Tue, 05 Feb 2013 15:45:34 GMT
Elmar, this seems to be a bug. Just to clarify, are you deploying the
aggregate in the same jvm as the
RunRemoteAsyncAE? The client's stop() method is not waiting for the AE
threads to finish. Its doing an immediate
stop.  The 2.4.0 version of UIMA-AS does support Queisce mode where the
service waits for all AE threads to finish
before proceeding with a shutdown. The problem is that this is not exposed
to the application in the UIMA-AS client API.

There are many changes in the 2.4.0 but I suspect the one that is effecting
you is that all UIMA-AS threads
are now daemon threads. Those threads dont block the jvm on System.exit().
The 2.3.1 used non-daemon threads
causing the jvm to hang while waiting for AE threads to finish.

I will create a JIRA for this and provide a fix soon.

Thanks, JC

On Tue, Feb 5, 2013 at 6:08 AM, Elmar Haußmann <
haussmann@informatik.uni-freiburg.de> wrote:

> Hello,
> since we upgraded from UIMA-AS 2.3.1 to 2.4.0 we are having problems with
> the destroy methods of some components not being executed properly.
> We are using the provided RunRemoteAsyncAE class with a collection reader
> (-c) and deploy an aggreate AE containing remotely scaled-out components.
> The aggregate AE has a co-located CAS Consumer at the end, which writes a
> single big ZIP file with all the results. The ZIP's OutputStream is closed
> in the destroy method. After upgrading to AS 2.4.0 the destroy method is
> often not called at all or interrupted during execution resulting in
> corrupt ZIP files. I suspect it is because in RunRemoteAsyncAE.java:
> private void stop() {
>   try {
>     uimaEEEngine.stop();
>     } catch( Exception e) {
>   }
>   System.exit(1);
> }
> the call to uimaEEEngine.stop() is non-blocking and afterwards
> System.exit(1) directly quits the JVM, apparently interrupting proper
> clean-up. Waiting some time after calling uimaEEEngine.stop() or removing
> System.exit() completely results in proper cleanup, but is only a
> work-around.
> Is this a bug? Is there a way to check whether the engine has stopped
> successfully or what is the suggested way to work around this? Also, I am
> wondering why this was never a problem in UIMA-AS 2.3.1 where this code is
> identical.
> Thanks for any help!
> Regards, Elmar

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message