This behavior seems to be caused by a bug in the uima-as. In the async aggregate there is a single thread servicing an input queue. This thread is blocked (by design) until the input CAS is returned back to the client. Only than the service thread is allowed to grab the next CAS. This design prevents concurrent processing of input CASes in async aggregate where CasPool size > 1. The blocking was motivated by the desire to enforce fair load balancing where each service(process) only takes as many CASes at it can process. The enforcing of fair load balancing is the right thing to do. The problem is with the implementation.
I will be working on solving this shortly. Should be fixed in the upcoming 2.4.2 uima-as release.For now I created JIRA for this problem https://issues.apache.org/jira/browse/UIMA-3160 JC JC On Wed, Aug 7, 2013 at 3:19 PM, Jaroslaw Cwiklik <uim...@gmail.com> wrote: > Instead of speculating, I decided to setup a test with similar > configuration ( casPool=6) and am noticing similar > problem. It appears that the input queue is drained one CAS at a time as > if there was only one thread processing > an input queue. > > Investigating... > > JC > > > On Wed, Aug 7, 2013 at 3:14 PM, Eddie Epstein <eaepst...@gmail.com> wrote: > >> Scaling via async=false and the number of instances = 6 DOES speed the >> >> > pipeline up by 6x, so I think the client is working correctly. It seems >> to >> > just be an issue when the async=true. I checked in the JMX console with >> > async=true and slow annotator = 6 instances and inside JMX UIMA reports >> > there are 6 instances of slow annotator configured. So it appears the >> > configuration is getting set right inside of UIMA. >> > >> > Other thoughts? >> > >> >> use JMX and double check the casPool size = 6? >> >> Eddie >> > >
