[ https://issues.apache.org/jira/browse/KAFKA-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454140#comment-13454140 ]
Jun Rao commented on KAFKA-391: ------------------------------- Thanks for patch v2. Some comments. 20. It's a good idea to create a case class of TopicPartition. This helps 2 things: (1) Tuple doesn't exist in java and javaapi.ProducerRequest currently uses tuple. (2) This avoids things like x._1._1, which is harder to understand. Similarly, should we create a case class of ProducerResponsStatus that wraps (errrocode, offset)? 21. javaapi.ProduceRequest should use java map, instead of scala map. javaapi.SyncProducer should return a java version of ProducerResponse. Thinking about it. Should we even provide a javaapi for SyncProducer since everyone should really be using the high level Producer api? In other words, SyncProducer probably is not our public api for clients. For consumers, we likely still need to provide a java version of SimpleConsumer since there may be applications that want to control the fetch offset. 23. It doesn't look like that we have a java version of FetchRequest. We should add that and use it in the java version of SimpleConsumer. 24. FetchResponse: We probably should add a helper method errorCode(topic, partition)? 25. AbstractFetchThread: can use the pattern response.data.foreach{ case(key, partitionData) => } 26. KafkaApis.handleFetchRequest(): can use the pattern in #25 too. > Producer request and response classes should use maps > ----------------------------------------------------- > > Key: KAFKA-391 > URL: https://issues.apache.org/jira/browse/KAFKA-391 > Project: Kafka > Issue Type: Bug > Reporter: Joel Koshy > Assignee: Joel Koshy > Labels: optimization > Fix For: 0.8 > > Attachments: KAFKA-391-draft-r1374069.patch, KAFKA-391-v2.patch > > > Producer response contains two arrays of error codes and offsets - the > ordering in these arrays correspond to the flattened ordering of the request > arrays. > It would be better to switch to maps in the request and response as this > would make the code clearer and more efficient (right now, linear scans are > used in handling producer acks). > We can probably do the same in the fetch request/response. -- 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