Yes, the aggregate is deployed into the same JVM as the RunRemoteAsyncAE. For now we are fine with the workaround, but a fix would certainly be great! Thanks for the info, Jaroslaw!
Elmar Am 05.02.2013 16:45, schrieb Jaroslaw Cwiklik:
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 < [email protected]> 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
