MINOR: Fix ConsumerBounceTest to wait for consumer close

[rajinisivaram]

No description provided.

[rajinisivaram]

@ijuma Can you take a look (and merge if it is ok), please? Thank you!

This is a fix for the failure in https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5268/

java.util.ConcurrentModificationException: KafkaConsumer is not safe for multi-threaded access
	at org.apache.kafka.clients.consumer.KafkaConsumer.acquire(KafkaConsumer.java:1638)
	at org.apache.kafka.clients.consumer.KafkaConsumer.close(KafkaConsumer.java:1536)
	at org.apache.kafka.clients.consumer.KafkaConsumer.close(KafkaConsumer.java:1514)
	at kafka.api.IntegrationTestHarness.$anonfun$tearDown$2(IntegrationTestHarness.scala:99)
	at kafka.api.IntegrationTestHarness.$anonfun$tearDown$2$adapted(IntegrationTestHarness.scala:99)

[asfbot]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5273/
Test PASSed (JDK 8 and Scala 2.12).

[asfbot]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5289/
Test PASSed (JDK 7 and Scala 2.11).

[ijuma]

Thanks for the PR. I think the actual issue here is that we don't wait for the executor's tasks to terminate in the tearDown before we try to close the consumers. If we do that, then we should not have the issue reported here.

One of the get calls you added still seems worthwhile. The other one, I am less sure about.

[ijuma]

Is this needed? It seems like waitForRebalance would do the job, no?

[ijuma]

Maybe we don't need a variable and we can just call get on the result?

[ijuma]

This is a bit tricky. Maybe we should just leave as it was. The issue is that close throwing an exception is a bug and if we do the try/finally, we may obscure the original exception if super.tearDown itself throws an exception.

[rajinisivaram]

Closing this PR since the test was updated in commit 031da88.