[
https://issues.apache.org/jira/browse/KAFKA-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Ye updated KAFKA-537:
--------------------------
Attachment: kafka_537_v3.diff
Thanks for the comments, to address then:
1. ConsumerConfig
1. Every config value has a comment explaining its purpose. Please can you add
this for the new config "clientid" ?
--- added
2. I wonder if specifying a default value of empty string is useful ? Maybe
groupid makes more sense or no default at all.
--- Agree, empty string is not meaningful at all. So what about set it default
to groupid, also this empty string "DefaultClientId" is kept and used as
default value of FetchRequest and FetchRequestBuilder. (This default value is
only used in testing, when used by real consumer, the clientId will be set to
the clientId of the consumer config
2. FetchRequest
2.1 According to coding convention, every constant is in camel case with first
letter capital. Please can you change replicaFetcherClientId to
ReplicaFetcherClientId ?
--- changed
3. KafkaApis
3.1 Fix the typo - private def appendToLocalLog(producerRquest:
ProducerRequest): Iterable[ProduceResult] = {
--- new patch does not affect KafkaApis.scala now, it should be addressed in
other patches
3.2 Let's fix the requestLogger to print the clientId. This allows us to have a
meaningful access log for Kafka where requests can be traced back to client ids.
--- in requestLogger.trace("Handling fetch request " + fetchRequest.toString),
the fetchRequest.toString should also contain the clientId, so I think we don't
need do it separately
4. ReplicaFetcherThread
4.1 Every replica's clientId is "replica fetcher". I wonder if we can add the
replica's id/host/both to the replica's client id. This will allow us to
differentiate amongst requests from the various replicas at the leader.
--- added broker host and port in the clientId
5. FetchRequestBuilder
Right now, we are depending on the user to not re-create the
FetchRequestBuilder each time. How about making the builder a singleton so that
is not possible ? That way, we can guarantee that it is initialized to 0 only
one per client.
--- We cannot make it a singleton because the fetchMap within each request
builder cannot be shared
> expose clientId and correlationId in ConsumerConfig
> ---------------------------------------------------
>
> Key: KAFKA-537
> URL: https://issues.apache.org/jira/browse/KAFKA-537
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Yang Ye
> Labels: bugs, newbie
> Fix For: 0.8
>
> Attachments: kafka_537_v1.diff, kafka_537_v2.diff, kafka_537_v3.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> We need to expose clientId and correlationId in ConsumerConfig and use it
> properly in AbstractFetcherThread. For follower fetchers, we should set the
> clientId to a special string, something list "follower".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
