@Harald Berghoff Thank you for responding . Please find my responses below in bold - the machine names from the error log are the expected ones? So this basically means: env-2 is example1.com and example2.com is your hdfs master node (port 8020 should be hdfs file service from the name node)? ------ Yes, env-2 is example1.com and example2.com is hdfs master node Are all the issues related to the communication between env-2 and your name node, or do you have other hosts involved as well? -------- Yes, Other hosts are involved as well . Issue is seen other nodes as well. does the process on env-1 start 5 times a day, or is it started once and continues to run (sleeping instead of terminating)? --------- In env -1 , process runs once and continues to run . Only 5 files are moved to HDFS in a single day . We don't restart any process. the ticket renewal on env-1 is identical to the ticket renewal on env-2? ------ ticket renewal is identical in both the env. I am just wondering if it is possible, that your process on env-2
only takes the ticket at start-up, and when the ticket expires, it just
doesn't pick the renewed ticket? If after a restart of your processes on
env-2 all authentication issues are gone for the next around 20h, this
might be the case. And if on env-1 the process is starting 5 times a day
instead of continuously running it might be the reason that the issue
is not occure on env-1. ------ In env-1 , the process is continuously running and we don't restart the process. ------- In env-2 , when the GSS issue pops up, we restart our process and all authentication issues are gone for the next around 20 h. My issue here is, why restart is needed for env-2 . As, in env-1 , all works good without any restart . As I have mentioned in my previous comment, the only difference between env-1 and env-2 is the load and amount of files are moved to HDFS simultaneously is huge in env-2. Please comment, if you need any more information for analysis. Thank you
... View more
