[
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.
