uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry Cwiklik (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Closed: (UIMA-1726) Long GC causes UIMA AS service to loose broker connection and marks the client as dead
Date Fri, 26 Mar 2010 15:40:27 GMT

     [ https://issues.apache.org/jira/browse/UIMA-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jerry Cwiklik closed UIMA-1726.

       Resolution: Fixed
    Fix Version/s: 2.3AS

Removed DoNotProcess list as means of tracking disconnected clients. To detect dead clients
and to optimize processing, the code checks for existence of a temp reply queue in the broker's
JMX MBeanServer registry. If the temp queue exists, the message is processed. If the queue
lookup fails, the message is dropped. A temp reply queue exists in the same broker that manages
service input queue. The code creates a connection to a JMX MBeanServer on initial request
message and caches it for subsequent lookups. If the broker is configured to not use jmx,
the optimization is not performed and every message is processed. Such requests fail when
a reply is attempted and the temp queue doesnt exists due to client termination. The code
supports: tcp, http, as well as failover in the broker url. 
The default jmx port used for creating connection to broker's MBeanServer is 1099. To override
this, add this property: -Dactivemq.broker.jmx.port=XXX to the service startup command

> Long GC causes UIMA AS service to loose broker connection and marks the client as dead
> --------------------------------------------------------------------------------------
>                 Key: UIMA-1726
>                 URL: https://issues.apache.org/jira/browse/UIMA-1726
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3AS
> When the JVMs GC takes a long time, the UIMA AS fails to validate the broker connection
and proceeds to close it as if the broker died. It seems that the long GC freezes the jvm
and prevents the low level socket pinging to work correctly. This pinging is a mechanism by
which the low level AMQ code relies upon to detect a broker failure. In this case, the broker
is actually fine. The side effect of the above is that the UIMA AS service falsely adds the
client to the DoNotProcess list. This is an optimization that was recently added that prevents
wasting processing cycles while handling CASes that are known to have come from clients that
had gone away. Each CAS origin is checked against that list and if there is a match the CAS
is thrown away. It seems that we need a better mechanism to detect broker failure.  

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message