You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jun Rao (JIRA)" <ji...@apache.org> on 2013/03/04 18:59:13 UTC

[jira] [Closed] (KAFKA-97) SocketServer.scala refers to Handler-specific variables

     [ https://issues.apache.org/jira/browse/KAFKA-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jun Rao closed KAFKA-97.
------------------------

    
> SocketServer.scala refers to Handler-specific variables
> -------------------------------------------------------
>
>                 Key: KAFKA-97
>                 URL: https://issues.apache.org/jira/browse/KAFKA-97
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jay Kreps
>            Assignee: Jun Rao
>            Priority: Minor
>             Fix For: 0.8
>
>
> There is meant to be a separation between the socket server and the kafka server. The socket server doesn't know anything about kafka, it is a set of classes that take a request handler implementation, reads requests and writes responses. It is like a 300 line version of netty. Some logging slipped in that is specific to the KafkaHandler implementation. This is a violation of concerns and should be fixed, it is kind of like the map/reduce framework referencing stuff in a particular map/reduce job. If we want to refactor the handlers to better be able to give the name to a particular request that is good, but nothing in kafka.network should depend on anything but kafka.utils. Having worked on projects where we screwed this up i am a little sensitive--the network stuff is complex enough even if we don't mix it in with kafka logic, we want it to be testable on its own.
> Here is the code (beginning on SocketServer.scala, line 267):
>     if(requestLogger.isTraceEnabled) {
>       requestTypeId match {
>         case RequestKeys.Produce =>
>           requestLogger.trace("Handling produce request from " + channelFor(key).socket.getRemoteSocketAddress())
>         case RequestKeys.Fetch =>
>           requestLogger.trace("Handling fetch request from " + channelFor(key).socket.getRemoteSocketAddress())
>         case RequestKeys.MultiFetch =>
>           requestLogger.trace("Handling multi-fetch request from " + channelFor(key).socket.getRemoteSocketAddress())
>         case RequestKeys.MultiProduce =>
>           requestLogger.trace("Handling multi-produce request from " + channelFor(key).socket.getRemoteSocketAddress())
>         case RequestKeys.Offsets =>
>           requestLogger.trace("Handling offset request from " + channelFor(key).socket.getRemoteSocketAddress())
>         case _ => throw new InvalidRequestException("No mapping found for handler id " + requestTypeId)
>       }
>     }

--
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