[
https://issues.apache.org/jira/browse/SAMZA-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297314#comment-14297314
]
Yan Fang commented on SAMZA-503:
--------------------------------
Thanks for reviewing.
{quote}
Minor nit: fetchTp1 = true seems not to be needed (or should have a comment
explaining why it's there). Feel free to commit optimistically.
{quote}
This is to control the BrokerProxy thread to fetch more messages or not (sleep)
by changing the value of "needMoreMessages" in sink. Does this make sense? Will
add comment for it if yes.
{quote}
I agree with you. (1) and (2) had been what I'd been thinking we'd get if we
added IncomingMessageEnvelope.getMaxOffset(). The OffsetManager could expose
checkpointed offset, max offset, and max offset - checkpointed offset. The
BrokerProxy could expose current offset, max offset, and messages behind high
watermark.
{quote}
Opened SAMZA-539 and SAMZA-540. Feel free to add comments there or modify the
description.
* Though I am not sure what the "max offset" in OffsetManager mean here. Is it
the latest offset in the incoming stream?
* getMaxOffset() returns the latest offset in the incoming stream or the latest
checkpointed offset?
> Lag gauge very slow to update for slow jobs
> -------------------------------------------
>
> Key: SAMZA-503
> URL: https://issues.apache.org/jira/browse/SAMZA-503
> Project: Samza
> Issue Type: Bug
> Components: metrics
> Affects Versions: 0.8.0
> Environment: Mac OS X, Oracle Java 7, ProcessJobFactory
> Reporter: Roger Hoover
> Assignee: Yan Fang
> Fix For: 0.9.0
>
> Attachments: SAMZA-503.1.patch, SAMZA-503.2.patch, SAMZA-503.patch
>
>
> For slow jobs, the
> KafkaSystemConsumerMetrics.%s-%s-messages-behind-high-watermark) gauge does
> not get updated very often.
> To reproduce:
> * Create a job that processes one message and sleeps for 5 seconds
> * Create it's input topic but do not populate it yet
> * Start the job
> * Load 1000s of messages to it's input topic. You can keep adding messages
> with a "watch -n 1 <kafka console producer command>"
> What happens:
> * Run jconsole to view the JMX metrics
> * The %s-%s-messages-behind-high-watermark gauge will stay at 0 for a LONG
> time (~10 minutes?) before finally updating.
> What should happen:
> * The gauge should get updated at a reasonable interval (a least every few
> seconds)
> I think what's happening is that the BrokerProxy only updates the high
> watermark when a consumer is ready for more messages. When the job is so
> slow, this rarely happens to the metric doesn't get updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
