[ 
https://issues.apache.org/jira/browse/KAFKA-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762495#comment-15762495
 ] 

ASF GitHub Bot commented on KAFKA-4526:
---------------------------------------

GitHub user apurvam opened a pull request:

    https://github.com/apache/kafka/pull/2278

    KAFKA-4526 - Disable throttling test until it can be fixed correctly.

    At present, the test is fragile in the sense that the console consumer
    has to start and be initialized before the verifiable producer begins
    producing in the produce-consume-validate loop.
    
    If this doesn't happen, the consumer will miss messages at the head of
    the log and the test will fail.
    
    At present, the consumer is considered inited once it has a PID. This is
    a weak assumption. The plan is to poll appropriate metrics (like
    partition assignment), and use those as a proxy for consumer
    initialization. That work will be tracked in a separate ticket. For now,
    we will disable the tests so that we can get the builds healthy again.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apurvam/kafka 
KAFKA-4526-throttling-test-failures

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/kafka/pull/2278.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2278
    
----
commit d7a0e0b9b69e52ca222f18409b3edb6663db0135
Author: Apurva Mehta <apurva.1...@gmail.com>
Date:   2016-12-19T22:19:29Z

    KAFKA-4526 - Disable throttling test until it can be fixed correctly.
    
    At present, the test is fragile in the sense that the console consumer
    has to start and be initialized before the verifiable producer begins
    producing in the produce-consume-validate loop.
    
    If this doesn't happen, the consumer will miss messages at the head of
    the log and the test will fail.
    
    At present, the consumer is considered inited once it has a PID. This is
    a weak assumption. The plan is to poll appropriate metrics (like
    partition assignment), and use those as a proxy for consumer
    initialization. That work will be tracked in a separate ticket. For now,
    we will disable the tests so that we can get the builds healthy again.

----


> Transient failure in ThrottlingTest.test_throttled_reassignment
> ---------------------------------------------------------------
>
>                 Key: KAFKA-4526
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4526
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Ewen Cheslack-Postava
>            Assignee: Apurva Mehta
>              Labels: system-test-failure, system-tests
>             Fix For: 0.10.2.0
>
>
> This test is seeing transient failures sometimes
> {quote}
> Module: kafkatest.tests.core.throttling_test
> Class:  ThrottlingTest
> Method: test_throttled_reassignment
> Arguments:
> {
>   "bounce_brokers": false
> }
> {quote}
> This happens with both bounce_brokers = true and false. Fails with
> {quote}
> AssertionError: 1646 acked message did not make it to the Consumer. They are: 
> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19...plus 
> 1626 more. Total Acked: 174799, Total Consumed: 173153. We validated that the 
> first 1000 of these missing messages correctly made it into Kafka's data 
> files. This suggests they were lost on their way to the consumer.
> {quote}
> See 
> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/2016-12-12--001.1481535295--apache--trunk--62e043a/report.html
>  for an example.
> Note that there are a number of similar bug reports for different tests: 
> https://issues.apache.org/jira/issues/?jql=text%20~%20%22acked%20message%20did%20not%20make%20it%20to%20the%20Consumer%22%20and%20project%20%3D%20Kafka
>  I am wondering if we have a wrong ack setting somewhere that we should be 
> specifying as acks=all but is only defaulting to 0?
> It also seems interesting that the missing messages in these recent failures 
> seem to always start at 0...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to