[ https://issues.apache.org/jira/browse/KAFKA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417832#comment-13417832 ]
Jay Kreps commented on KAFKA-398: --------------------------------- Hey Guozhang, I think we can't take these socket server changes as is. The idea behind the network/ sub-package is that it should be stand-alone and have no knowledge that it is part of kafka. So it is not appropriate to special case individual request types there. That is fine though, I think this is a side point for the code you are writing. I recommend you just hack away, when it comes time to port it over to 0.8 I will gladly do the refactoring to the socket server to do this in a clean way. If you get stuck for more than 10 mins on anything grab me and I will help you hack it further. I think the following things probably need to change in 0.8: 1. RequestChannel probably needs some renaming as the request/response terminology no longer makes sense. 2. The run() loop in SocketServer.Processor needs a fix for the read/write logic. Currently we have: if(key.isReadable) read(key) else if(key.isWritable) write(key) But now a given socket may be both readable and writable for different requests. To make this work we will need to tweak the way we handle in-flight partitially written requests. We assume there can be only one partitial request for any given socket at one time, but now there could be two--one inbound and one outbound. These are very simple changes but need some care and thought. 3. We need to always be ready for reading even if we are currently writing. Incidently I think this is the same fix that would be required to allow the client to multi-plex requests over a single connection which is a valuable feature too. > Enhance SocketServer to Enable Sending Requests > ----------------------------------------------- > > Key: KAFKA-398 > URL: https://issues.apache.org/jira/browse/KAFKA-398 > Project: Kafka > Issue Type: Improvement > Components: core > Affects Versions: 0.7, 0.8 > Reporter: Guozhang Wang > Labels: features > Attachments: kafka-398-0.7-v1.patch, kafka-398-0.7-v2.patch > > > Currently the SocketServer is only used for reactively receiving requests and > send responses but not used for pro-actively send requests and receive > responses. Hence it does not need to remember which channel/key correspond to > which consumer. > On the other hand, there are cases such as consumer coordinator that needs > SocketServer to send requests and receive responses to the consumers. > It would be nice to add this functionality such that an API can be called > with the id string and the request message, and the SocketServer will figure > out which channel to use and write that message to the key's attachment and > set the flag as WRITABLE so that the processor can then send it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira