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 <[email protected]> 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 <[email protected]> >> 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: [email protected] > > Geschäftsführer: Dr. med. Philipp Daumke, Dr. Kornél Markó > Sitz der Gesellschaft: Freiburg i. Br. > AG Freiburg i. Br., HRB 701080 > >
