[ 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)