[
https://issues.apache.org/jira/browse/KAFKA-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943539#comment-14943539
]
Ismael Juma commented on KAFKA-2609:
------------------------------------
Interesting, good to know. Regarding the question about producer and consumer
handling renegotiation, there are these method in `NetworkClient`:
{code}
public boolean ready(Node node, long now) {
if (isReady(node, now))
return true;
if (connectionStates.canConnect(node.idString(), now))
// if we are interested in sending to a node and we don't have a
connection to it, initiate one
initiateConnect(node, now);
return false;
}
public boolean isReady(Node node, long now) {
// if we need to update our metadata now declare all requests unready
to make metadata requests first
// priority
return !metadataUpdater.isUpdateDue(now) &&
canSendRequest(node.idString());
}
private boolean canSendRequest(String node) {
return connectionStates.isConnected(node) &&
selector.isChannelReady(node) && inFlightRequests.canSendMore(node);
}
{code}
They are meant to avoid sending a message to a channel that is not ready (eg
handshake is taking place). However, as you say, we need a test that triggers
renegotiation in the middle of consumption or production to verify that it
works as expected.
> SSL renegotiation code paths need more tests
> --------------------------------------------
>
> Key: KAFKA-2609
> URL: https://issues.apache.org/jira/browse/KAFKA-2609
> Project: Kafka
> Issue Type: Test
> Affects Versions: 0.9.0.0
> Reporter: Rajini Sivaram
> Assignee: Rajini Sivaram
> Fix For: 0.9.0.0
>
>
> If renegotiation is triggered when read interest is off, at the moment it
> looks like read interest is never turned back on. More unit tests are
> required to test different renegotiation scenarios since these are much
> harder to exercise in system tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
