[
https://issues.apache.org/jira/browse/HDFS-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702706#comment-14702706
]
Rakesh R commented on HDFS-8287:
--------------------------------
Thanks [~kaisasak], latest patch looks better. I've few more minor suggestions,
please take a look at it.
- Please make {{generatorClosed}} volatile.
- Add exit log message at the end of {{ParityGenerator#run()}} method. Can do
something like,
{code}
Log.info("ParityGenerator thread: "+ getName()+ " for path: " + src + " is
terminating!");
{code}
- Earlier {{#writeParityCells()}} method will be throwing IOException back to
the caller about the exceptional situation. Now, with the new asynchronous
approach it is suppressing the exception and continue writing. Below are the
two such cases where it can hit exception. We should improve this by notifying
the writers, isn't it?
{code}
+ try {
+ writeParity(i, buffers[i],
+ cellBuffers[currentIndex].getChecksumArray(i));
+ } catch (IOException e) {
+ LOG.warn("Caught exception ", e);
+ }
{code}
{code}
+ parityGenerator.setUncaughtExceptionHandler(
+ new Thread.UncaughtExceptionHandler() {
+ @Override
+ public void uncaughtException(Thread t, Throwable e) {
+ LOG.warn("Uncaught exception is threw by ParityGenerator: ", e);
+ }
+ }
{code}
> DFSStripedOutputStream.writeChunk should not wait for writing parity
> ---------------------------------------------------------------------
>
> Key: HDFS-8287
> URL: https://issues.apache.org/jira/browse/HDFS-8287
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Kai Sasaki
> Attachments: HDFS-8287-HDFS-7285.00.patch,
> HDFS-8287-HDFS-7285.01.patch, HDFS-8287-HDFS-7285.02.patch,
> HDFS-8287-HDFS-7285.03.patch, HDFS-8287-HDFS-7285.04.patch
>
>
> When a stripping cell is full, writeChunk computes and generates parity
> packets. It sequentially calls waitAndQueuePacket so that user client cannot
> continue to write data until it finishes.
> We should allow user client to continue writing instead but not blocking it
> when writing parity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
