[
https://issues.apache.org/jira/browse/UIMA-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eddie Epstein reopened UIMA-3519:
---------------------------------
The problem still happens at even higher loads. Broker %CPU only goes up to
half of what it did before, but with the same slow message delivery to the
overloaded queue.
Since the problem only occurs with a large number of clients, it is so far only
seen when client processes have many threads making requests to the same
service. Adding a client-side option to synchronize requests for a particular
service among all threads in a process will reduce the likelihood of broker
overload.
> JMS service stub causes broker problems at high load
> ----------------------------------------------------
>
> Key: UIMA-3519
> URL: https://issues.apache.org/jira/browse/UIMA-3519
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Eddie Epstein
> Assignee: Eddie Epstein
>
> Scenario:
> A UIMA aggregate includes a JMS remote service, the aggregate is deployed in
> multiple threads and in multiple processes such that there are close to 1000
> total pipeline threads, and the CAS rate going to the remote service is
> greater than about 100 per second.
> In this situation, which is common for a DUCC job, then the AMQ broker will
> start using an abnormally high amount of CPU while slowly delivering CASes to
> the remote service instances, resulting in poor throughput.
> Up until now the JMS service stub instantiates a new UimaAsynchronousEngine
> object for every thread. The problem does not occur if instead the JMS
> service stub instantiates a single UimaAsynchronousEngine object and uses it
> for all process threads pointing at the same remote service.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
