[
https://issues.apache.org/jira/browse/KAFKA-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803645#comment-13803645
]
Guozhang Wang commented on KAFKA-1079:
--------------------------------------
Thanks for the patch Kostya, a couple of comments:
1. Is there a particular reason you wanted to use
val port = TestUtils.choosePort()
instead of
val port = TestUtils.choosePort?
2. I think it is better to keep
val topics = List(("test4", 0), ("test1", 0), ("test2", 0), ("test3", 0));
in testMultiProduce as it specifies the topic/partition more clear.
> Liars in PrimitiveApiTest that promise to test api in compression mode, but
> don't do this actually
> --------------------------------------------------------------------------------------------------
>
> Key: KAFKA-1079
> URL: https://issues.apache.org/jira/browse/KAFKA-1079
> Project: Kafka
> Issue Type: Test
> Components: core
> Affects Versions: 0.8
> Reporter: Kostya Golikov
> Priority: Minor
> Labels: newbie, test
> Attachments: testing-with-compression-producer.patch
>
>
> Long time ago (0.7) we had ByteBufferMessageSet as a part of api and it's
> allowed us to control compression. Times goes on and now PrimitiveApiTest
> have methods that promise to test api with compression enabled, but in fact
> they don't. Moreover this methods almost entirely copy their counterparts
> without compression. In particular I'm talking about
> `testProduceAndMultiFetch` / `testProduceAndMultiFetchWithCompression` and
> `testMultiProduce`/`testMultiProduceWithCompression` pairs.
> The fix could be super-easy and soundness -- just parameterize methods with
> producer of each type (with/without compression). Sadly but it isn't feasible
> for junit3, so straightforward solution is to do the same ugly thing as
> `testDefaultEncoderProducerAndFetchWithCompression` method does -- forget
> about class-wide producer and roll-out it's own. I will attach path if that
> is a problem indeed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
