[
https://issues.apache.org/jira/browse/HADOOP-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573932#action_12573932
]
Tsz Wo (Nicholas), SZE commented on HADOOP-2346:
------------------------------------------------
- For ProviderInfo.next, I agreed that your implementation is more efficient
and use less memory. +1 since this class is a low level class.
- >This won't work because most channels are both Readable and Writable.
Actually, I think the boolean variable read can be eliminated. See below.
- > 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?
In the constructor of SocketIOWithTimeout, you already enforce if read is true,
channel must be a ReadableByteChannel, otherwise, channel must be a
WritableByteChannel. I do not see a good reason to put ReadableByteChannel and
WritableByteChannel in the same class and use a boolean to remember whether it
is doing read or write.
I suggest to add two classes, say ReadableSocketIOWithTimeout and
WritableSocketIOWithTimeout, both extending SocketIOWithTimeout. Then, the
fields layout will become:
{code}
abstract class SocketIOWithTimeout {
private long timeout;
private boolean closed = false;
}
class ReadableSocketIOWithTimeout extends SocketIOWithTimeout {
private ReadableByteChannel in;
}
class WritableSocketIOWithTimeout extends SocketIOWithTimeout {
private WritableByteChannel out;
}
{code}
- Also found some typs in SocketIOWithTimeout.java
line 59, /* => /**
line 119, mutliple => multiple
line 247, canceled => canceled
> 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, 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.
