[
https://issues.apache.org/jira/browse/KAFKA-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155841#comment-15155841
]
Anna Povzner edited comment on KAFKA-3256 at 2/21/16 1:40 AM:
--------------------------------------------------------------
[~becket_qin] The "No JSON object could be decoded" failure is also caused by
ConsoleConsumer outputting timestamp type and timestamp. If I remove that
output from ConsoleConsumer, I stop getting this failure.
Also, once I did that, reassign_partitions_test also started passing.
So, it leads me to believe that there is some common test tool which expects a
particular *format* of an output, rather than a test expecting a specific
output.
What was the reason for outputting timestamp type and timestamp in
ConsoleConsumer? If it does not bring much value, I propose to just got back to
the original format of outputting key and value in ConsoleConsumer. I think
that would fix most of the tests.
was (Author: apovzner):
[~becket_qin] The "No JSON object could be decoded" failure is also caused by
ConsoleConsumer outputting timestamp type and timestamp. If I remove that
output from ConsoleConsumer, I stop getting this failure.
Also, once I did not, reassign_partitions_test also started passing.
So, it leads me to believe that there is some common test tool which expects a
particular *format* of an output, rather than a test expecting a specific
output.
What was the reason for outputting timestamp type and timestamp in
ConsoleConsumer? If it does not bring much value, I propose to just got back to
the original format of outputting key and value in ConsoleConsumer. I think
that would fix most of the tests.
> Large number of system test failures
> ------------------------------------
>
> Key: KAFKA-3256
> URL: https://issues.apache.org/jira/browse/KAFKA-3256
> Project: Kafka
> Issue Type: Bug
> Reporter: Geoff Anderson
> Assignee: Jiangjie Qin
>
> Confluent's nightly run of the kafka system tests reported a large number of
> failures beginning 2/20/2016
> Test run: 2016-02-19--001.1455897182--apache--trunk--eee9522/
> Link:
> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/2016-02-19--001.1455897182--apache--trunk--eee9522/report.html
> Pass: 136
> Fail: 0
> Test run: 2016-02-20--001.1455979842--apache--trunk--5caa800/
> Link:
> http://confluent-kafka-system-test-results.s3-us-west-2.amazonaws.com/2016-02-20--001.1455979842--apache--trunk--5caa800/report.html
> Pass: 72
> Fail: 64
> I.e. trunk@eee9522 was the last passing run, and trunk@5caa800 had a large
> number of failures.
> Given its complexity, the most likely culprit is 45c8195fa, and I confirmed
> this is the first commit with failures on a small number of tests.
> [~becket_qin] do you mind investigating?
> {code}
> commit 5caa800e217c6b83f62ee3e6b5f02f56e331b309
> Author: Jun Rao <jun...@gmail.com>
> Date: Fri Feb 19 09:40:59 2016 -0800
> trivial fix to authorization CLI table
> commit 45c8195fa14c766b200c720f316836dbb84e9d8b
> Author: Jiangjie Qin <becket....@gmail.com>
> Date: Fri Feb 19 07:56:40 2016 -0800
> KAFKA-3025; Added timetamp to Message and use relative offset.
> commit eee95228fabe1643baa016a2d49fb0a9fe2c66bd
> Author: Yasuhiro Matsuda <yasuh...@confluent.io>
> Date: Thu Feb 18 09:39:30 2016 +0800
> MINOR: remove streams config params from producer/consumer configs
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
