You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pinot.apache.org by "navina (via GitHub)" <gi...@apache.org> on 2023/03/15 21:40:39 UTC

[GitHub] [pinot] navina commented on pull request #10418: Fix ramping delay caused by long lasting sequence of unfiltered messa…

navina commented on PR #10418:
URL: https://github.com/apache/pinot/pull/10418#issuecomment-1470881958

   > When all events are filtered and no actual events are processed, set consumption delay to zero as we are caught up processing actual events.
   
   All events filtered in a given batch doesn't imply that we are caught up. In this scenario, the consumer returned messages , however, it was all filtered for whatever reason (is it tombstones today??). This scenario should be treated differently than when fetch messages doesn't return any messages from the consumer.  Have I misunderstood the hidden assumptions in the current realtime segment data manager's implementation ?
   
   > This does not affect metric reports in active tables that have incoming events, only inactive tables that have long sequences of filtered events.
   
   What do you mean by "inactive tables"? Are these tables that are not consuming or tables that are consuming from an empty source? Or something else?


-- 
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.

To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org

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


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org