question Re: Dr who name is converted to different string while queueing in Support Questions

Dr who name is converted to different string while queueing

hadoopNoob — Fri, 16 Sep 2022 13:34:20 GMT

Hello,

Resource manager is giving warning and exiting "

Name dr.who is converted to dr_dot_who when it is used as a queue name."

any possible solution ? complete log for warnings is below

3:08:49.689 PM	WARN	QueuePlacementRule	Name dr.who is converted to dr_dot_who when it is used as a queue name.
3:08:49.689 PM	INFO	FairScheduler	Accepted application application_1533729822715_0025 from user: dr.who, in queue: root.users.dr_dot_who, currently num of applications: 21
3:08:49.690 PM	INFO	RMAppImpl	application_1533729822715_0025 State change from SUBMITTED to ACCEPTED on event = APP_ACCEPTED
3:08:49.690 PM	INFO	ApplicationMasterService	Registering app attempt : appattempt_1533729822715_0025_000001
3:08:49.690 PM	INFO	RMAppAttemptImpl	appattempt_1533729822715_0025_000001 State change from NEW to SUBMITTED on event = START
3:08:49.690 PM	INFO	FairScheduler	Added Application Attempt appattempt_1533729822715_0025_000001 to scheduler from user: dr.who
3:08:49.691 PM	INFO	RMAppAttemptImpl	appattempt_1533729822715_0025_000001 State change from SUBMITTED to SCHEDULED on event = ATTEMPT_ADDED
3:08:50.820 PM	WARN	RMAppImpl	The specific max attempts: 3 for application: 7 is invalid, because it is out of the range [1, 2]. Use the global max attempts instead.
3:08:50.820 PM	INFO	ClientRMService	Application with id 7 submitted by user dr.who
3:08:50.820 PM	INFO	RMAuditLogger	USER=dr.who OPERATION=Submit Application Request TARGET=ClientRMService RESULT=SUCCESS APPID=application_1533729822715_0007
3:08:50.821 PM	INFO	RMAppImpl	Storing application with id application_1533729822715_0007
3:08:50.822 PM	INFO	RMAppImpl	application_1533729822715_0007 State change from NEW to NEW_SAVING on event = START
3:08:50.822 PM	INFO	RMStateStore	Storing info for app: application_1533729822715_0007
3:08:50.822 PM	INFO	RMAppImpl	application_1533729822715_0007 State change from NEW_SAVING to SUBMITTED on event = APP_NEW_SAVED
3:08:50.822 PM	WARN	QueuePlacementRule	Name dr.who is converted to dr_dot_who when it is used as a queue name.

Re: Dr who name is converted to different string while queueing

hadoopNoob — Mon, 13 Aug 2018 12:39:48 GMT

issue solved !

Re: Dr who name is converted to different string while queueing

sai23 — Sat, 18 Aug 2018 16:41:54 GMT

Can you please tell me the step by step procedure

Thanks in advance

Re: Dr who name is converted to different string while queueing

hadoopNoob — Sat, 18 Aug 2018 17:34:53 GMT

Sure, please place your logs here first, so i can see is the issue similar

Re: Dr who name is converted to different string while queueing

sai23 — Sun, 19 Aug 2018 07:22:52 GMT

please tell me how to get the logs

Re: Dr who name is converted to different string while queueing

hadoopNoob — Sun, 19 Aug 2018 07:25:18 GMT

Go to, resource manager of yarn, from there you can get the logs

Re: Dr who name is converted to different string while queueing

buyaoshuohua — Mon, 10 Sep 2018 03:13:20 GMT

Can you please tell me how to deal with it.i have the same logs with you

Re: Dr who name is converted to different string while queueing

hadoopNoob — Mon, 17 Sep 2018 11:57:43 GMT

sorry for late reply, are you still facing this issue ?

Re: Dr who name is converted to different string while queueing

buyaoshuohua — Tue, 18 Sep 2018 01:11:50 GMT

i've solved it,thanks

Re: Dr who name is converted to different string while queueing

Vivjad13 — Thu, 18 Oct 2018 11:24:29 GMT

May I know how did you solved the issue

Re: Dr who name is converted to different string while queueing

hadoopNoob — Thu, 18 Oct 2018 11:26:38 GMT

check this thread, answer is here http://community.cloudera.com/t5/Cloudera-Manager-Installation/Yarn-Node-Manager-unexpected-exists-occurring-after/m-p/79048#M14736

Re: Dr who name is converted to different string while queueing

buyaoshuohua — Fri, 19 Oct 2018 01:20:19 GMT

Since I was hit with the mining virus, it would continuously submit the mining procedure to port 8088, so I changed my yarn port to 8089 and solved it