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 Tue, 10 Jun 2014 19:27:16 GMT
If the broker dies you will loose all CASes sent to a service. If a service
fails to find a reply queue (broker is gone) it
will just drop the reply, log a message and move on. The temp queue is gone
and even if you restart the broker
the temp queue will not be recovered. The UIMA-AS (both the service and
client) are designed to recover from broker failures
and any new work (after broker restart) will be proceed.

On the UIMA-AS client side make sure you setup a Process timeout. I am not
aware of any issues regarding the client
not timing out if the timeout is used. Is there evidence in the client log
that the internal UIMA-AS timer popped?

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.

Jerry



On Tue, Jun 10, 2014 at 8:08 AM, Frank Enders <frank.enders@averbis.com>
wrote:

> Hi Jerry,
>
> thanks for the reply!
>
> We have this situation when the broker gets terminated while requests are
> currently being processed.
> Apparently, those requests neither recover after the broker gets restarted
> nor time out when UimaAsynchronousEngine.Timeout is reached.
>
> Is this the expected behaviour when a broker is getting terminated
> unexpectedly?
>
> Thanks and all the best
> Frank
>
> Am 22.04.2014 15:22, schrieb Jaroslaw Cwiklik:
>
>  Hi, do you see any evidence in the service log of any problems? The client
>> side will block in sendAndReceive() until a reply comes back from the
>> service.
>>
>> You can attach jconsole to the service to see if it is hung somewhere.
>> Please check UIMA-AS README for instructions how to configure service to
>> enable
>> jmx.
>>
>> Jerry
>>
>>
>> On Tue, Apr 22, 2014 at 4:38 AM, Frank Enders <frank.enders@averbis.com>
>> wrote:
>>
>>  Dear all,
>>>
>>> we are using a synchronous sendAndReceiveCAS() call within a webservice
>>> endpoint (JAX WS RI).
>>> Doing so, in some cases we find hanging requests, which are not getting
>>> completed.
>>> I am attaching a corresponding part of a thread dump.
>>>
>>> We are using UIMA AS 2.4.0. Application environment is Tomcat 6.0.32, JAX
>>> WS RI 2.1.7.
>>>
>>> Have you encountered a similar behaviour?
>>>
>>> Thank and all the best
>>> Frank
>>>
>>> "catalina-exec-77" Id=3412437 in WAITING cpu=2083520 ms usr=2056580 ms
>>> blocked 547742 for -1 ms waited 297560 for -1 ms
>>>      locks java.util.concurrent.locks.ReentrantLock$NonfairSync@19c88785
>>>      at sun.misc.Unsafe.park(Native Method)
>>>      - waiting on (a java.util.concurrent.Semaphore$NonfairSync@3c3939fc
>>> )
>>>      at java.util.concurrent.locks.LockSupport.park(LockSupport.
>>> java:156)
>>>      at java.util.concurrent.locks.AbstractQueuedSynchronizer.
>>> parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>>>      at java.util.concurrent.locks.AbstractQueuedSynchronizer.
>>> doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>>>      at java.util.concurrent.locks.AbstractQueuedSynchronizer.
>>> acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>>>      at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
>>>      at org.apache.uima.adapter.jms.client.
>>> BaseUIMAAsynchronousEngineComm
>>> on_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineComm
>>> on_impl.java:2062)
>>>      at org.apache.uima.adapter.jms.client.
>>> BaseUIMAAsynchronousEngineComm
>>> on_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineComm
>>> on_impl.java:1952)
>>>      at de.averbis.extraction.[...].webservice.WebservicePort.
>>> getLanguage(WebservicePort.java:1214)
>>>      at sun.reflect.GeneratedMethodAccessor2765.invoke(Unknown Source)
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>> DelegatingMethodAccessorImpl.java:25)
>>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>>      at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(
>>> InstanceResolver.java:246)
>>>      at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
>>>      at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(
>>> EndpointMethodHandler.java:257)
>>>      at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(
>>> SEIInvokerTube.java:93)
>>>      at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
>>>      at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
>>>      at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
>>>      at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
>>>      - locked (a com.sun.xml.ws.api.pipe.Fiber@5a8fe32) index 19 frame
>>> com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
>>>      at com.sun.xml.ws.server.WSEndpointImpl$2.process(
>>> WSEndpointImpl.java:243)
>>>      at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.
>>> handle(HttpAdapter.java:471)
>>>      at com.sun.xml.ws.transport.http.HttpAdapter.handle(
>>> HttpAdapter.java:244)
>>>      at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(
>>> ServletAdapter.java:135)
>>>      at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.
>>> doGet(WSServletDelegate.java:129)
>>>      at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.
>>> doPost(WSServletDelegate.java:160)
>>>      at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(
>>> WSServlet.java:75)
>>>      at javax.servlet.http.HttpServlet.service(Unknown Source)
>>>      at javax.servlet.http.HttpServlet.service(Unknown Source)
>>>      at org.apache.catalina.core.ApplicationFilterChain.
>>> internalDoFilter(Unknown
>>> Source)
>>>      at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown
>>> Source)
>>>      at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown
>>> Source)
>>>      at org.apache.catalina.core.StandardContextValve.invoke(Unknown
>>> Source)
>>>      at org.apache.catalina.core.StandardHostValve.invoke(Unknown
>>> Source)
>>>      at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown
>>> Source)
>>>      at org.apache.catalina.valves.AccessLogValve.invoke(Unknown Source)
>>>      at org.apache.catalina.core.StandardEngineValve.invoke(Unknown
>>> Source)
>>>      at org.apache.catalina.connector.CoyoteAdapter.service(Unknown
>>> Source)
>>>      at org.apache.coyote.ajp.AjpAprProcessor.process(Unknown Source)
>>>      at org.apache.coyote.ajp.AjpAprProtocol$
>>> AjpConnectionHandler.process(Unknown
>>> Source)
>>>      at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.
>>> run(Unknown
>>> Source)
>>>      at java.util.concurrent.ThreadPoolExecutor$Worker.
>>> runTask(ThreadPoolExecutor.java:895)
>>>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>> ThreadPoolExecutor.java:918)
>>>      at java.lang.Thread.run(Thread.java:662)
>>>
>>>
>
> --
> 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