[
https://issues.apache.org/jira/browse/KAFKA-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566215#comment-13566215
]
Jay Kreps commented on KAFKA-736:
---------------------------------
This is basically good, but the comments and naming are all just carrying
through specifics of producer behavior into the network layer which is a no-no.
Instead, think of this as a general feature you are implementing:
1. server enqueues one request at a time
2. null as the response send indicates no response
This is a nice feature for our socket server to have.
Specifically:
1. RequestChannel.getFakeProducerResponse? Let's not add this as a public
method on the thing that handles request queueing to our network server. That
doesn't seem like part of the contract of a request queue. Can you remove that
and the getShutdownReceive producer request that victor seems to have hacked
in. The socket server's idea of a request is just a byte buffer. There
shouldn't be any notion of producers or anything like that.
2. SocketServer.processNewResponses() the actual logic here is good, using a
null send is a very logical way to say "no response". Please remove the comment
about producers and num.acks and just describe the feature you have
implemented: null responseSend means no response to send. This is just part of
the contract of socket server.
3. SocketServer.processNewResponses() fix misformatted else statement.
4. SyncProducer.send--this is an api change is that going to break anything?
Can we just have it return null?
5. SyncProducer.doSend--this sends a generic request, you can't add numacks
since acks are specific to ProducerRequest.
6. Not sure if I get why we need to override required.request.acks. If we want
to override is the a generic place to do that instead of each test?
7. It would be good to add a unit test for one-way requests in the socket
server.
8. It would be good to add a unit test for the producer num.acks=0 feature.
We also should do a quick perf test on your machine to assess the impact of
only reading one request at a time (if any).
> Add an option to the 0.8 producer to mimic 0.7 producer behavior
> ----------------------------------------------------------------
>
> Key: KAFKA-736
> URL: https://issues.apache.org/jira/browse/KAFKA-736
> Project: Kafka
> Issue Type: Improvement
> Components: producer
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Blocker
> Labels: p2, replication-performance
> Attachments: kafka-736-draft.patch, kafka-736-v1.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I profiled a producer throughput benchmark between a producer and a remote
> broker. It turns out that the background send threads spends ~97% of its time
> waiting to read the acknowledgement from the broker.
> I propose we change the current behavior of request.required.acks=0 to mean
> no acknowledgement from the broker. This will mimic the 0.7 producer behavior
> and will enable tuning the producer for very high throughput.
--
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
