[ 
https://issues.apache.org/jira/browse/HADOOP-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572793#action_12572793
 ] 

Raghu Angadi commented on HADOOP-2346:
--------------------------------------

- > [...] {{boolean read = channel instanceof ReadableByteChannel;}}
-- This won't work because most channels are both Readable and Writable.

- >[...] Then, the runtime checking can be eliminated
-- Can't really eliminate runtime checking. For e.g. SocketInputStream's 
channel should be both SelectableChannel and a ReadableByteChannel. How do we 
enforce that without runtime check?

- > SocketIOWithTimeout.isClosed() should check [...]
-- sure. Not much different but will  make the change.

- > Instead of implementing a linked list by ProviderInfo.next [...]
-- :) reminds of earlier days. I implemented only because we don't remove from 
the list. If we want an advantage, we iterate on the list (mostly has just one 
elemement) twice everytime we wait.. so avoids allocation of iterator twice. I 
think this is ok.. let me know if we should. Using java.util.LinkedList does 
not make number of lines less, with all the generics stuff, it surely takes 
more bytes :).



> DataNode should have timeout on socket writes.
> ----------------------------------------------
>
>                 Key: HADOOP-2346
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2346
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.15.1
>            Reporter: Raghu Angadi
>            Assignee: Raghu Angadi
>             Fix For: 0.17.0
>
>         Attachments: HADOOP-2346.patch, HADOOP-2346.patch, HADOOP-2346.patch, 
> HADOOP-2346.patch, HADOOP-2346.patch, HADOOP-2346.patch, HADOOP-2346.patch, 
> HADOOP-2346.patch, HADOOP-2346.patch, HADOOP-2346.patch
>
>
> If a client opens a file and stops reading in the middle, DataNode thread 
> writing the data could be stuck forever. For DataNode sockets we set read 
> timeout but not write timeout. I think we should add a write(data, timeout) 
> method in IOUtils that assumes it the underlying FileChannel is non-blocking.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to