[
https://issues.apache.org/jira/browse/UIMA-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry Cwiklik closed UIMA-2354.
-------------------------------
Resolution: Fixed
Associate zero-permit, shared semaphore with a receiving thread via ThreadLocal
and also associate the same semaphore with a InProcessCache entry of the CAS.
When the CAS is delivered to the delegate's queue, block the receiving thread
on semaphore.aquire(). When the CAS is fully processed and returned back to a
client, the semaphore is released and the receiving thread proceeds to take
another CAS from a service queue.
> UIMA AS aggregate fetches too many msgs from its service queue
> --------------------------------------------------------------
>
> Key: UIMA-2354
> URL: https://issues.apache.org/jira/browse/UIMA-2354
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Jerry Cwiklik
> Assignee: Jerry Cwiklik
> Fix For: 2.4.0AS
>
>
> In this scenario UIMA AS aggregate thread receives a msg from a service
> queue, desarializes a CAS, fetches the next step from the FC, and deliveres
> the CAS to a delegate's queue. Once the CAS is delivered to the delegate's
> queue, the receiving thread is done and proceeds to fetch another msg from a
> service queue. This is wrong and totaly breaks prefetch=0 idea and effects
> load balancing if there are multiple instances of UIMA AS aggregate. The
> receiving thread should not fetch another msg while the previous CAS is still
> in-play. The code should block the receiving thread after a CAS is delivered
> to a delegate's queue until the CAS is fully processed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
