[
https://issues.apache.org/jira/browse/KAFKA-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680061#comment-14680061
]
Ismael Juma edited comment on KAFKA-2411 at 8/10/15 1:00 PM:
-------------------------------------------------------------
[~gwenshap], the time has come for you to pass your knowledge along. :) I would
like some feedback on the following commit that updates `KafkaServer`:
https://github.com/ijuma/kafka/commit/f5ef130b7405e5ad5088cdf0fbc633c51860ab47
It works correctly as far as I can tell (all tests pass, including
`RollingBounceTest`). I am particularly interested in feedback regarding the
following (but any and all feedback is welcome):
* The various parameters passed to do `Selector` constructor and
`Selector.connect` (I reused existing configs, but I am not sure if that's
appropriate).
* The way I tried to replicate the behaviour of `controllerSocketTimeoutMs`.
Regarding `ControllerChannelManager`, we can either keep the existing design
with one `RequestSendThread` and `selector` per `toBroker` (in which case the
changes are mechanical) or we could have a single thread and `selector` for all
brokers. Or something in-between. Thoughts?
was (Author: ijuma):
[~gwenshap], the time has come for you to pass your knowledge along. :) I would
like some feedback on the following commit that updates `KafkaServer`:
https://github.com/ijuma/kafka/commit/94d095bf8d6540ada6f733ff05f87cdc358d4ea4
It works correctly as far as I can tell (all tests pass, including
`RollingBounceTest`). I am particularly interested in feedback regarding the
following (but any and all feedback is welcome):
* The various parameters passed to do `Selector` constructor and
`Selector.connect` (I reused existing configs, but I am not sure if that's
appropriate).
* The way I tried to replicate the behaviour of `controllerSocketTimeoutMs`.
Regarding `ControllerChannelManager`, we can either keep the existing design
with one `RequestSendThread` and `selector` per `toBroker` (in which case the
changes are mechanical) or we could have a single thread and `selector` for all
brokers. Or something in-between. Thoughts?
> remove usage of BlockingChannel in the broker
> ---------------------------------------------
>
> Key: KAFKA-2411
> URL: https://issues.apache.org/jira/browse/KAFKA-2411
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Reporter: Jun Rao
> Assignee: Ismael Juma
> Fix For: 0.8.3
>
>
> In KAFKA-1690, we are adding the SSL support at Selector. However, there are
> still a few places where we use BlockingChannel for inter-broker
> communication. We need to replace those usage with Selector/NetworkClient to
> enable inter-broker communication over SSL. Specially, BlockingChannel is
> currently used in the following places.
> 1. ControllerChannelManager: for the controller to propagate metadata to the
> brokers.
> 2. KafkaServer: for the broker to send controlled shutdown request to the
> controller.
> 3. AbstractFetcherThread: for the follower to fetch data from the leader
> (through SimpleConsumer).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
