[
https://issues.apache.org/jira/browse/KAFKA-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804004#comment-13804004
]
Kostya Golikov commented on KAFKA-1079:
---------------------------------------
1. It is common convention in Scala to distinguish pure no arg functions from
side effecting ones. Since current implementation of choosePort creates
socket(s) and moreover can yield different results on different runs, I guess
it is pretty reasonable to put braces next to the method call.
2. Okay, I will revert this change.
> 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)