FUSE Message Broker
  1. FUSE Message Broker
  2. MB-377

Using small queue prefetch sizes cause all consumers to run as fast as the slowest consumer.

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 5.0.0.17-fuse, 5.1.0.0-fuse
    • Fix Version/s: 5.0.0.19-fuse
    • Component/s: broker
    • Labels:
      None
    • Environment:
      Servicemix 3.3.1.3 on Windows, probably on all platforms.
    • Similar Issues:
      Show 10 results 

      Description

      If you have a JMS producer sending messages to multiple consumers and you have the cacheLevel set to 3 or higher, eventually all consumers will run as slow as the slowest consumer.
      In the attached projects the SA sends messages to a MockOptimizer (JMS consumer) that has two threads. One sleeps for one second and the other sleeps for ten. Initially the thread sleeping for 1 second will consume most of the messages, but towards the end it will start to consume messages every ten seconds as well.

        Activity

        Hide
        Hiram Chirino
        added a comment -

        Attaching the junit case that confirms the bug.

        Show
        Hiram Chirino
        added a comment - Attaching the junit case that confirms the bug.
        Hide
        Hiram Chirino
        added a comment -

        The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full.

        I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.

        Show
        Hiram Chirino
        added a comment - The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full. I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.
        Hide
        Hiram Chirino
        added a comment -

        https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.

        Show
        Hiram Chirino
        added a comment - https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.
        Hide
        Hiram Chirino
        added a comment -

        Update.. we are now currently evaluating and testing the attached patch. It fixes the slow producer problem but we are trying to verify that it as not caused any other regressions.

        Show
        Hiram Chirino
        added a comment - Update.. we are now currently evaluating and testing the attached patch. It fixes the slow producer problem but we are trying to verify that it as not caused any other regressions.
        Hide
        Gary Tully
        added a comment -

        fix from https://issues.apache.org/activemq/browse/AMQ-1866 is now on fuse fixes branch ready for .19 release.

        Show
        Gary Tully
        added a comment - fix from https://issues.apache.org/activemq/browse/AMQ-1866 is now on fuse fixes branch ready for .19 release.

          People

          • Assignee:
            Hiram Chirino
            Reporter:
            Martin Murphy
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: