[
https://issues.apache.org/jira/browse/KAFKA-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13771557#comment-13771557
]
Jay Kreps commented on KAFKA-1043:
----------------------------------
Why not just configure the socket buffer size based on the maximum I/O size we
want to block on? Say 512k.
We had two issues--one was blocking on the full write which I think/hope we
fixed. The second was that even if we do that you still have to block for one
socket buffers worth of data. The simplest thing is just to set this buffer to
a reasonable default.
Decoupling the socket from the selectors is possible but probably pretty
complex for a minor bug fix. I also think this only works as long as we
maintain the current setup where we only allow a single in-flight request at a
time per socket. If we allowed multiple requests then the socket must remain
registered with some selector and you have to send the response back to that
selector.
> Time-consuming FetchRequest could block other request in the response queue
> ---------------------------------------------------------------------------
>
> Key: KAFKA-1043
> URL: https://issues.apache.org/jira/browse/KAFKA-1043
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8.1
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Fix For: 0.8, 0.8.1
>
>
> Since in SocketServer the processor who takes any request is also responsible
> for writing the response for that request, we make each processor owning its
> own response queue. If a FetchRequest takes irregularly long time to write
> the channel buffer it would block all other responses in the queue.
--
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
