UIMA
  1. UIMA
  2. UIMA-2354

UIMA AS aggregate fetches too many msgs from its service queue

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4.0AS
    • Component/s: Async Scaleout
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Jerry Cwiklik added a comment -

        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.

        Show
        Jerry Cwiklik added a comment - 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.

          People

          • Assignee:
            Jerry Cwiklik
            Reporter:
            Jerry Cwiklik
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development