[jira] [Commented] (HDFS-14646) Standby NameNode should terminate the FsImage put process immediately if the peer NN is not in the appropriate state to receive an image.
[
https://issues.apache.org/jira/browse/HDFS-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887659#comment-16887659
]
Hadoop QA commented on HDFS-14646:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
39s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} trunk Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 19m
33s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
12s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
13m 47s{color} | {color:green} branch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
20s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} trunk passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{color} | {color:green} hadoop-hdfs-project/hadoop-hdfs: The patch generated
0 new + 71 unchanged - 1 fixed = 71 total (was 72) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} shadedclient {color} | {color:green}
13m 5s{color} | {color:green} patch has no errors when building and testing
our client artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}109m 19s{color}
| {color:red} hadoop-hdfs in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}170m 21s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hdfs.server.namenode.TestCheckpoint |
| | hadoop.hdfs.server.datanode.TestDirectoryScanner |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=18.09.7 Server=18.09.7 Image:yetus/hadoop:bdbca0e53b4 |
| JIRA Issue | HDFS-14646 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12975116/HDFS-14646.000.patch |
| Optional Tests | dupname asflicense compile javac javadoc mvninstall
mvnsite unit shadedclient findbugs checkstyle |
| uname | Linux b94518d832cd 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4
22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/patchprocess/precommit/personality/provided.sh |
| git revision | trunk / 73e6ffc |
| maven | version: Apache Maven 3.3.9 |
| Default Java | 1.8.0_212 |
| findbugs | v3.1.0-RC1 |
| whitespace |
https://builds.apache.org/job/PreCommit-HDFS-Build/27249/artifact/out/whitespace-eol.txt
|
| unit |
[jira] [Commented] (HDFS-14646) Standby NameNode should terminate the FsImage put process immediately if the peer NN is not in the appropriate state to receive an image.
[
https://issues.apache.org/jira/browse/HDFS-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885871#comment-16885871
]
Hadoop QA commented on HDFS-14646:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HDFS-14646 does not apply to trunk. Rebase required? Wrong
Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HDFS-14646 |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/27234/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Standby NameNode should terminate the FsImage put process immediately if the
> peer NN is not in the appropriate state to receive an image.
> -
>
> Key: HDFS-14646
> URL: https://issues.apache.org/jira/browse/HDFS-14646
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
>Affects Versions: 3.1.2
>Reporter: Xudong Cao
>Assignee: Xudong Cao
>Priority: Major
> Attachments: blockedInWritingSocket.png, get1.png, get2.png,
> largeSendQ.png
>
>
> *Problem Description:*
> In the multi-NameNode scenario, when a SNN uploads a FsImage, it will put
> the image to all other NNs (whether the peer NN is an ANN or not), and even
> if the peer NN immediately replies with an error (such as
> TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult
> .OLD_TRANSACTION_ID_FAILURE, etc.), the local SNN will not terminate the put
> process immediately, but will put the FsImage completely to the peer NN, and
> will not read the peer NN's reply until the put is completed.
> In a relatively large HDFS cluster, the size of FsImage can often reach about
> 30GB. In this case, this invalid put brings two problems:
> # Wasting time and bandwidth.
> # Since the ImageServlet of the peer NN no longer receives the FsImage, the
> socket Send-Q of the local SNN is very large, and the ImageUpload thread will
> be blocked in writing socket for a long time, eventually causing the local
> StandbyCheckpointer thread often blocked for several hours.
> *An example is as follows:*
> In the following figure, the local NN 100.76.3.234 is a SNN, the peer NN
> 100.76.3.170 is another SNN, and the 8080 is NN Http port. When the local SNN
> starts to put the FsImage, 170 will reply with a NOT_ACTIVE_NAMENODE_FAILURE
> error immediately. In this case, the local SNN should terminate put
> immediately, but in fact, local SNN has to wait until the image has been
> completely put to the peer NN，and then can read the response.
> # At this time, since the ImageServlet of the peer NN no longer receives the
> FsImage, the socket Send-Q of the local SNN is very large:
> !largeSendQ.png!
> 2. Moreover, the local SNN's ImageUpload thread will be blocked in
> writing socket for a long time:
> !blockedInWritingSocket.png! .
>
> 3. Eventually, the StandbyCheckpointer thread of local SNN is waiting
> for the execution result of the ImageUpload thread, blocking in Future.get(),
> and the blocking time may be as long as several hours:
> !get1.png!
>
> !get2.png!
>
>
> *Solution:*
> When the local SNN plans to put a FsImage to the peer NN, it need to test
> whether he really need to put it at this time. The test process is:
> # Establish an HTTP connection with the peer NN, send the put request, and
> then immediately read the response (this is the key point). If the peer NN
> replies any of the following errors (TransferResult.AUTHENTICATION_FAILURE,
> TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult.
> OLD_TRANSACTION_ID_FAILURE), immediately terminate the put process.
> # If the peer NN is indeed the Active NameNode AND it's now in the
> appropriate state to receive an image, it will reply an HTTP response 410
> (HttpServletResponse.SC_GONE, which is TransferResult.UNEXPECTED_FAILURE). At
> this time, the local SNN can really begin to put the image.
> *Note:*
> This problem needs to be reproduced in a large cluster (the size of FsImage
> in our cluster is about 30GB). Therefore, unit testing is difficult to write.
> In our cluster, after the modification, the problem has been solved and there
> is no such thing as a large backlog of Send-Q.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HDFS-14646) Standby NameNode should terminate the FsImage put process immediately if the peer NN is not in the appropriate state to receive an image.
[ https://issues.apache.org/jira/browse/HDFS-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885404#comment-16885404 ] Íñigo Goiri commented on HDFS-14646: We run subclusters with 4 Namenodes and I'm not aware of us seeing the issue. I'll go over the logs to see if it's indeed happening. At this point the time to load the FSImage is our current time sink so this might just be overlooked. HDFS-6440 seems to leave a TODO open which is somewhat solved here. It looks like an optimization worth adding in any case. Not sure how to test this... adding synthetic delays might make the running time too long; lowering the time outs might have some other side effects too. > Standby NameNode should terminate the FsImage put process immediately if the > peer NN is not in the appropriate state to receive an image. > - > > Key: HDFS-14646 > URL: https://issues.apache.org/jira/browse/HDFS-14646 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.1.2 >Reporter: Xudong Cao >Assignee: Xudong Cao >Priority: Major > Attachments: blockedInWritingSocket.png, get1.png, get2.png, > largeSendQ.png > > > *Problem Description:* > In the multi-NameNode scenario, when a SNN uploads a FsImage, it will put > the image to all other NNs (whether the peer NN is an ANN or not), and even > if the peer NN immediately replies with an error (such as > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult > .OLD_TRANSACTION_ID_FAILURE, etc.), the local SNN will not terminate the put > process immediately, but will put the FsImage completely to the peer NN, and > will not read the peer NN's reply until the put is completed. > In a relatively large HDFS cluster, the size of FsImage can often reach about > 30GB. In this case, this invalid put brings two problems: > # Wasting time and bandwidth. > # Since the ImageServlet of the peer NN no longer receives the FsImage, the > socket Send-Q of the local SNN is very large, and the ImageUpload thread will > be blocked in writing socket for a long time, eventually causing the local > StandbyCheckpointer thread often blocked for several hours. > *An example is as follows:* > In the following figure, the local NN 100.76.3.234 is a SNN, the peer NN > 100.76.3.170 is another SNN, and the 8080 is NN Http port. When the local SNN > starts to put the FsImage, 170 will reply with a NOT_ACTIVE_NAMENODE_FAILURE > error immediately. In this case, the local SNN should terminate put > immediately, but in fact, local SNN has to wait until the image has been > completely put to the peer NN，and then can read the response. > # At this time, since the ImageServlet of the peer NN no longer receives the > FsImage, the socket Send-Q of the local SNN is very large: > !largeSendQ.png! > 2. Moreover, the local SNN's ImageUpload thread will be blocked in > writing socket for a long time: > !blockedInWritingSocket.png! . > > 3. Eventually, the StandbyCheckpointer thread of local SNN is waiting > for the execution result of the ImageUpload thread, blocking in Future.get(), > and the blocking time may be as long as several hours: > !get1.png! > > !get2.png! > > > *Solution:* > When the local SNN plans to put a FsImage to the peer NN, it need to test > whether he really need to put it at this time. The test process is: > # Establish an HTTP connection with the peer NN, send the put request, and > then immediately read the response (this is the key point). If the peer NN > replies any of the following errors (TransferResult.AUTHENTICATION_FAILURE, > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult. > OLD_TRANSACTION_ID_FAILURE), immediately terminate the put process. > # If the peer NN is indeed the Active NameNode AND it's now in the > appropriate state to receive an image, it will reply an HTTP response 410 > (HttpServletResponse.SC_GONE, which is TransferResult.UNEXPECTED_FAILURE). At > this time, the local SNN can really begin to put the image. > *Note:* > This problem needs to be reproduced in a large cluster (the size of FsImage > in our cluster is about 30GB). Therefore, unit testing is difficult to write. > In our cluster, after the modification, the problem has been solved and there > is no such thing as a large backlog of Send-Q. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14646) Standby NameNode should terminate the FsImage put process immediately if the peer NN is not in the appropriate state to receive an image.
[ https://issues.apache.org/jira/browse/HDFS-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885341#comment-16885341 ] Erik Krogen commented on HDFS-14646: [~xudongcao] thanks for reporting this, it seems like a great improvement. [~csun] or [~elgoiri], I believe you have experience running large clusters with multiple SbNNs, I just want to verify if you have also seen this issue? > Standby NameNode should terminate the FsImage put process immediately if the > peer NN is not in the appropriate state to receive an image. > - > > Key: HDFS-14646 > URL: https://issues.apache.org/jira/browse/HDFS-14646 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.1.2 >Reporter: Xudong Cao >Assignee: Xudong Cao >Priority: Major > Attachments: blockedInWritingSocket.png, get1.png, get2.png, > largeSendQ.png > > > *Problem Description:* > In the multi-NameNode scenario, when a SNN uploads a FsImage, it will put > the image to all other NNs (whether the peer NN is an ANN or not), and even > if the peer NN immediately replies with an error (such as > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult > .OLD_TRANSACTION_ID_FAILURE, etc.), the local SNN will not terminate the put > process immediately, but will put the FsImage completely to the peer NN, and > will not read the peer NN's reply until the put is completed. > In a relatively large HDFS cluster, the size of FsImage can often reach about > 30GB. In this case, this invalid put brings two problems: > # Wasting time and bandwidth. > # Since the ImageServlet of the peer NN no longer receives the FsImage, the > socket Send-Q of the local SNN is very large, and the ImageUpload thread will > be blocked in writing socket for a long time, eventually causing the local > StandbyCheckpointer thread often blocked for several hours. > *An example is as follows:* > In the following figure, the local NN 100.76.3.234 is a SNN, the peer NN > 100.76.3.170 is another SNN, and the 8080 is NN Http port. When the local SNN > starts to put the FsImage, 170 will reply with a NOT_ACTIVE_NAMENODE_FAILURE > error immediately. In this case, the local SNN should terminate put > immediately, but in fact, local SNN has to wait until the image has been > completely put to the peer NN，and then can read the response. > # At this time, since the ImageServlet of the peer NN no longer receives the > FsImage, the socket Send-Q of the local SNN is very large: > !largeSendQ.png! > 2. Moreover, the local SNN's ImageUpload thread will be blocked in > writing socket for a long time: > !blockedInWritingSocket.png! . > > 3. Eventually, the StandbyCheckpointer thread of local SNN is waiting > for the execution result of the ImageUpload thread, blocking in Future.get(), > and the blocking time may be as long as several hours: > !get1.png! > > !get2.png! > > > *Solution:* > When the local SNN plans to put a FsImage to the peer NN, it need to test > whether he really need to put it at this time. The test process is: > # Establish an HTTP connection with the peer NN, send the put request, and > then immediately read the response (this is the key point). If the peer NN > replies any of the following errors (TransferResult.AUTHENTICATION_FAILURE, > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult. > OLD_TRANSACTION_ID_FAILURE), immediately terminate the put process. > # If the peer NN is indeed the Active NameNode AND it's now in the > appropriate state to receive an image, it will reply an HTTP response 410 > (HttpServletResponse.SC_GONE, which is TransferResult.UNEXPECTED_FAILURE). At > this time, the local SNN can really begin to put the image. > *Note:* > This problem needs to be reproduced in a large cluster (the size of FsImage > in our cluster is about 30GB). Therefore, unit testing is difficult to write. > In our cluster, after the modification, the problem has been solved and there > is no such thing as a large backlog of Send-Q. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14646) Standby NameNode should terminate the FsImage put process immediately if the peer NN is not in the appropriate state to receive an image.
[ https://issues.apache.org/jira/browse/HDFS-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885107#comment-16885107 ] Xudong Cao commented on HDFS-14646: --- *Test Result:* > Standby NameNode should terminate the FsImage put process immediately if the > peer NN is not in the appropriate state to receive an image. > - > > Key: HDFS-14646 > URL: https://issues.apache.org/jira/browse/HDFS-14646 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs >Affects Versions: 3.1.2 >Reporter: Xudong Cao >Assignee: Xudong Cao >Priority: Major > Attachments: blockedInWritingSocket.png, get1.png, get2.png, > largeSendQ.png > > > *Problem Description:* > In the multi-NameNode scenario, when a SNN uploads a FsImage, it will put > the image to all other NNs (whether the peer NN is an ANN or not), and even > if the peer NN immediately replies with an error (such as > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult > .OLD_TRANSACTION_ID_FAILURE, etc.), the local SNN will not terminate the put > process immediately, but will put the FsImage completely to the peer NN, and > will not read the peer NN's reply until the put is completed. > In a relatively large HDFS cluster, the size of FsImage can often reach about > 30GB. In this case, this invalid put brings two problems: > # Wasting time and bandwidth. > # Since the ImageServlet of the peer NN no longer receives the FsImage, the > socket Send-Q of the local SNN is very large, and the ImageUpload thread will > be blocked in writing socket for a long time, eventually causing the local > StandbyCheckpointer thread often blocked for several hours. > *An example is as follows:* > In the following figure, the local NN 100.76.3.234 is a SNN, the peer NN > 100.76.3.170 is another SNN, and the 8080 is NN Http port. When the local SNN > starts to put the FsImage, 170 will reply with a NOT_ACTIVE_NAMENODE_FAILURE > error immediately. In this case, the local SNN should terminate put > immediately, but in fact, local SNN has to wait until the image has been > completely put to the peer NN，and then can read the response. > # At this time, since the ImageServlet of the peer NN no longer receives the > FsImage, the socket Send-Q of the local SNN is very large: > !largeSendQ.png! > 2. Moreover, the local SNN's ImageUpload thread will be blocked in > writing socket for a long time: > !blockedInWritingSocket.png! . > > 3. Eventually, the StandbyCheckpointer thread of local SNN is waiting > for the execution result of the ImageUpload thread, blocking in Future.get(), > and the blocking time may be as long as several hours: > !get1.png! > > !get2.png! > > > *Solution:* > When the local SNN plans to put a FsImage to the peer NN, it need to test > whether he really need to put it at this time. The test process is: > # Establish an HTTP connection with the peer NN, send the put request, and > then immediately read the response (this is the key point). If the peer NN > replies any of the following errors (TransferResult.AUTHENTICATION_FAILURE, > TransferResult.NOT_ACTIVE_NAMENODE_FAILURE, TransferResult. > OLD_TRANSACTION_ID_FAILURE), immediately terminate the put process. > # If the peer NN is indeed the Active NameNode AND it's now in the > appropriate state to receive an image, it will reply an HTTP response 410 > (HttpServletResponse.SC_GONE, which is TransferResult.UNEXPECTED_FAILURE). At > this time, the local SNN can really begin to put the image. > *Note:* > This problem needs to be reproduced in a large cluster (the size of FsImage > in our cluster is about 30GB). Therefore, unit testing is difficult to write. > In our cluster, after the modification, the problem has been solved and there > is no such thing as a large backlog of Send-Q. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
