You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2020/05/07 04:01:49 UTC

[GitHub] [pulsar] sijie commented on issue #6847: Reader skips over large block of messages after calling `seek`

sijie commented on issue #6847:
URL: https://github.com/apache/pulsar/issues/6847#issuecomment-625016062


   @gfredericks I moved the conversations here:
   
   ---
   
   from @gfredericks [comment](https://github.com/streamnative/pulsar/issues/931#issuecomment-624080127)
   
   Okay, I've figured out by analyzing the broker logs that this is is presumably due to the consumer_backlog_eviction policy:
   
   21:41:51.542 [pulsar-backlog-quota-checker-26-1] INFO  org.apache.pulsar.broker.service.BacklogQuotaManager - Backlog quota exceeded for topic [persistent://public/default/tmp-integers]. Applying [consumer_backlog_eviction] policy
   21:41:51.542 [pulsar-backlog-quota-checker-26-1] INFO  org.apache.bookkeeper.mledger.impl.ManagedCursorImpl - [public/default/persistent/tmp-integers] Skipping 12914 entries on cursor reader-ecf0525784
   I don't understand all of the pieces here, but I would say that if this is the expected behavior it is rather unideal. My interpretation of a Reader is that it intends to read every message; if the system can't handle that for some reason or another, it would at least be useful to be able to detect that from the read side so the reader can retry or propagate the failure.
   
   I'm going to keep researching the background issues so I can understand this better.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org