You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Jerry Cwiklik (JIRA)" <de...@uima.apache.org> on 2013/08/14 23:07:48 UTC

[jira] [Closed] (UIMA-3160) UIMA-AS not allowing concurrent processing of CASes in async aggregate

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

Jerry Cwiklik closed UIMA-3160.
-------------------------------

    Resolution: Fixed

Modified to use semaphore to throttle ingestion of CASes. The semaphore is initialized with a number of permits equal to the size of its cas pool - 1. The semaphore is acquired as soon as a CAS is dispatched to the first delegate in the flow. The semaphore is released when the CAS is fully processed. The thread blocks if no permits are available. This assures that the service only takes as many CASes from an input queue as it is capable of processing without waiting for a free instance of CAS from the cas pool.
                
> UIMA-AS not allowing concurrent processing of CASes in async aggregate
> ----------------------------------------------------------------------
>
>                 Key: UIMA-3160
>                 URL: https://issues.apache.org/jira/browse/UIMA-3160
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.4.1AS
>
>
> For deployments consisting of async aggregate, the uima-as does not allow concurrent processing of *input CASes*. In this design, the thread servicing an input queue is intentionally blocked until the input CAS is fully processed. Only than, the thread is allowed to dequeue the next CAS. This design was motivated by the desire to enforce fair load balancing where each service/process takes as many CASes as it can process without blocking waiting for a free instance of a CAS (from service CasPool). The motivation is still valid, but it looks like the implementation of the idea is wrong. 
> Suggestion is to force the service thread to fetch a CAS *before* trying to dequeue a CAS. This design ensures that the service only takes as many CASes from a queue as it is capable of processing. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira