kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-3601) fail fast when newer client connecting to older server
Date Wed, 11 Jan 2017 15:59:58 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818703#comment-15818703
] 

Colin P. McCabe commented on KAFKA-3601:
----------------------------------------

[~cpennello_opentable], I believe 0.8, 0.9 and older servers should disconnect 0.10.2.0 and
newer clients immediately.  The reason is because the 0.10.2.0 will send an {{ApiVersionsRequest}},
which the old server doesn't understand.  For 0.10.0.0 and newer servers, the client should
be able to talk to them (see KIP-97).

> fail fast when newer client connecting to older server
> ------------------------------------------------------
>
>                 Key: KAFKA-3601
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3601
>             Project: Kafka
>          Issue Type: Improvement
>          Components: consumer
>            Reporter: Chris Pennello
>            Assignee: Ashish K Singh
>
> I know that connecting with a newer client to an older server is forbidden, but I would
like to suggest that the behavior be that it predictably fail noisily, explicitly, and with
specific detail indicating why the failure occurred.
> As-is, trying to connect to a v0.8.1.1 cluster with a v0.9.1 client yields a hang when
trying to get a coordinator metadata update.
> (This may be related to KAFKA-1894.  I certainly did note {{poll(Long.MAX_VALUE)}} and
wept many tears.  At least we could include a TODO-commented constant in the code with a non-forever,
timeout, right?)
> {noformat}
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <1c8cadab> (a sun.nio.ch.Util$2)
> 	- locked <2324ec49> (a java.util.Collections$UnmodifiableSet)
> 	- locked <3f3f5e0b> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at org.apache.kafka.common.network.Selector.select(Selector.java:425)
> 	at org.apache.kafka.common.network.Selector.poll(Selector.java:254)
> 	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:256)
> 	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.clientPoll(ConsumerNetworkClient.java:320)
> 	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:213)
> 	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:193)
> 	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.awaitMetadataUpdate(ConsumerNetworkClient.java:134)
> 	at org.apache.kafka.clients.consumer.internals.AbstractCoordinator.ensureCoordinatorKnown(AbstractCoordinator.java:184)
> 	at org.apache.kafka.clients.consumer.KafkaConsumer.pollOnce(KafkaConsumer.java:886)
> 	at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:853)
> 	... my code that calls poll...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message