PFC and cursors

[Paul Gale <pa...@gmail.com>]

Hi,

I've read where message cursors should be used when PFC is turned off or
for when consumers fall behind producers. The doc states that in the normal
case, so-called, where consumers keep up with producers, does not involve a
pending cursor of any kind. The configured cursor is only engaged when a
consumer falls behind its producer.

What happens when a consumer catches back up with the producer: does the
configured cursor disengage resulting in messages being passed directly to
the dispatch queue, the way it did before the consumer fell behind? If not,
why?

Thanks,
Paul

Re: PFC and cursors

[Christian Posta <ch...@gmail.com>]

On Mon, Jul 8, 2013 at 1:52 PM, Paul Gale <pa...@gmail.com> wrote:

> Hi,
>
> I've read where message cursors should be used when PFC is turned off or
> for when consumers fall behind producers.

When PFC is turned off, you have to make sure that the broker can deal with
more messages coming in than it can handle especially in the case of
non-persistent messages (offline to disk, purge old messages, expire
messages, etc, etc)


> The doc states that in the normal
> case, so-called, where consumers keep up with producers, does not involve a
> pending cursor of any kind. The configured cursor is only engaged when a
> consumer falls behind its producer.
>
Pending cursors are used throughout the architecture to buffer messages
that are pending for dispatch.
In the normal case, messages are cached in memory (persistent and
non-persistent) thus can be delivered much faster. If consumers fall
behind, then they are no longer cached and are expected to live in a cursor
capable of handling overflow (disk for persistent messages,
filependingmessagecursor for non-persistent).


>
> What happens when a consumer catches back up with the producer: does the
> configured cursor disengage resulting in messages being passed directly to
> the dispatch queue, the way it did before the consumer fell behind? If not,
> why?
>
If consumer catches back up, cache will be used again and all will be good.



>
> Thanks,
> Paul
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta