uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslaw Cwiklik <uim...@gmail.com>
Subject Re: Hanging UIMA AS requests
Date Fri, 20 Jun 2014 14:29:03 GMT
Frank, yes the System.exit() is a big problem when deploying UIMA-AS in a
shared JVM.

There is a jvm wide setting to disable calling System.exit(). Use
-DdontKill when starting
Tomcat. It is not a solution, just a hack to get around this problem.

I will investigate if this could be removed. If I recall there are two
scenarios where UIMA-AS
decides to call exit():

1) Catching Java Error (OOM for example). This was put it to force JVM exit
on OOM which does not always happen.
2) AE error threshold (defined in deployment descriptor) is reached.

I'v created a JIRA for the future release of UIMA-AS to engineer a better
solution.

My first thought would be to have the UIMA-AS notify the service
wrapper/container
that it wants to shutdown instead of calling System.exit(). The container
would then
initiate a shutdown to clean things up. If you have any comments on this
please
comment here: https://issues.apache.org/jira/browse/UIMA-3905

Just FYI, there is a Release Candidate for UIMA-AS 2.6.0 being voted on
now. If there  are
no issues, it will be released soon. There are a number of fixes there to
deal with thread
cleanup.


 Jerry


On Wed, Jun 18, 2014 at 10:05 AM, Frank Enders <frank.enders@averbis.com>
wrote:

> Hi Jerry,
>
> thanks!
>
> When upgrading to 2.4.2 we observed some issues, which lead to a more
> general question.
>
> I suppose those problems are related to the way we deploy our endpoints.
> We wrote wrappers for both, the AMQ broker and UIMA AS endpints
> (RemoteAsyncAE_API), allowing us to run them within a (Tomcat) container.
> This way we distribute several AS endpoint by deploying them across
> multiple containers.
>
> The AMQ Broker, encapsulated within a war file, is being deployed in a
> container as well.
>
> This was needed for an IT environment, in which we are only allowed to
> deploy within containers without starting dedicated JVMs for each endpoint.
>
> Generally, this works quite well. But it seems that undeployment of
> those components, induced by shutting down their container, may result
> in scattered 'hangig' threads (both, on consumer and producer side).
>
> Is UIMA AS principally designed for being deployed within containers? Or
> do you think we will face further issues following this approach?
> I am aksing since in the recent AS sources we found occurrences of
> System.exit(), which is quite fatefull when running within a shared JVM ;)
>
> Thanks and all the best
> Frank
>
> Am 12.06.2014 16:09, schrieb Jaroslaw Cwiklik:
> > All you need is a reference to a thread that called sendAndReceive().
> Once
> > you have it, just call <myThread>.interrupt().
> >
> > I would still like to know more about the timer not working. Is there
> > anything in the log that shows the UIMA-AS timer expiring?
> >
> > I just ran a test and the following is in the log:
> >
> > Jun 12, 2014 10:07:17 AM org.apache.uima.aae.delegate.Delegate$1
> > Delegate.TimerTask.run
> > WARNING: Timeout While Waiting For Reply From
> > Delegate:SlowNoOpAnnotatorQueue1 Process CAS Request Timed Out.
> Configured
> > Reply Window Of 1,000. Cas Reference Id:-26e1fb2b:1469067657a:-7ff3
> > Jun 12, 2014 10:07:17 AM
> > org.apache.uima.adapter.jms.client.ClientServiceDelegate handleError
> > WARNING: Process Timeout - Uima AS Client Didn't Receive Process Reply
> > Within Configured Window Of:1,000 millis
> > Jun 12, 2014 10:07:17 AM
> > org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl
> > notifyOnTimout
> > WARNING: Request To Process Cas Has Timed-out.  Service
> > Queue:SlowNoOpAnnotatorQueue1. Broker: tcp://localhost.localdomain:61617
> > Cas Timed-out on host: 192.168.6.65
> >
> > Jerry
> >
> >
> > On Wed, Jun 11, 2014 at 6:30 PM, Frank Enders <frank.enders@averbis.com>
> > wrote:
> >
> >> Hi Jerry,
> >>
> >> Am 10.06.2014 21:27, schrieb Jaroslaw Cwiklik:
> >>
> >>  The 2.4.2 AS code also supports interrupts on a thread stuck in
> >>> sendAndReceive(). You can implement your own
> >>> timer if you like, and if it pops just interrupt the thread and try
> >>> calling
> >>> sendAndReceive() again. The subsequent call
> >>> should block until a new connection is established.
> >>>
> >>
> >> How would I do this? I don't find anything about this in the 2.4.2 docs.
> >>
> >> Thanks!
> >> Frank
> >>
> >
>
>
> --
> Averbis GmbH
> Tennenbacher Straße 11
> D-79106 Freiburg
>
> Fon: +49 (0) 761 - 203 976 92
> Fax: +49 (0) 761 - 203 976 94
> E-Mail: frank.enders@averbis.com
>
> Geschäftsführer: Dr. med. Philipp Daumke, Dr. Kornél Markó
> Sitz der Gesellschaft: Freiburg i. Br.
> AG Freiburg i. Br., HRB 701080
>

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