Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

AEM Publisher throwing maintenance exception in logs

Avatar

Level 2

We have two AEM Publishers and the below exception is continuously thrown on both the publishers.

 

29.04.2020 16:50:21.804 *INFO* [qtp279028224-11690] log.request 29/Apr/2020:16:50:21 +0000 [130007] -> GET /libs/granite/operations/config/maintenance/granite:daily.infinity.json HTTP/1.1
 
The maintenance jobs for daily and weekly is configured and working fine. Any other reason why this might be happening?
1 Accepted Solution

Avatar

Correct answer by
Employee

Hello Ashish,

It looks like it's trying to find the config for the task using the old location, instead of the new location /conf/global/settings/granite/operations/maintenance/granite_daily. The libs path does not exist, hence the 404.

The request was used in lower versions of AEM like AEM 6.2 to get maintenance task info, these request would not have any impact on the maintenance task run on AEM 6.3 and above.

Regards,

Vishu

View solution in original post

7 Replies

Avatar

Community Advisor

These are just "INFO" logs. Are you noticing these entries frequently on your logs?

Yes these are frequently in our logs. And due to this request combined with ACS Commons we noticed that The call that AEM is getting, that call in itself is 404 always, checked it on vanilla server.

 

Since the call is 404, it would invoke your error handler JSP.. and the vanity check code is throwing some code error, when the incoming URL pattern is: /libs/granite/operations/config/maintenance/granite:daily.infinity.json

 

So we had to wrap the 404.jsp to catch the exception.

 

Avatar

Employee

This is just an INFO log. You shouldn't be worried about it. You can ignore it.

Avatar

Level 2
Yes these are frequently in our logs. And due to this request combined with ACS Commons we noticed that The call that AEM is getting, that call in itself is 404 always, checked it on vanilla server. Since the call is 404, it would invoke your error handler JSP.. and the vanity check code is throwing some code error, when the incoming URL pattern is: /libs/granite/operations/config/maintenance/granite:daily.infinity.json So we had to wrap the 404.jsp to catch the exception.

Avatar

Correct answer by
Employee

Hello Ashish,

It looks like it's trying to find the config for the task using the old location, instead of the new location /conf/global/settings/granite/operations/maintenance/granite_daily. The libs path does not exist, hence the 404.

The request was used in lower versions of AEM like AEM 6.2 to get maintenance task info, these request would not have any impact on the maintenance task run on AEM 6.3 and above.

Regards,

Vishu

Avatar

Level 2
This is happening in AEM 6.5.2 . Due to this request combined with ACS Commons we noticed that The call that AEM is getting, that call in itself is 404 always, checked it on vanilla server. Since the call is 404, it would invoke your error handler JSP.. and the vanity check code is throwing some code error, when the incoming URL pattern is: /libs/granite/operations/config/maintenance/granite:daily.infinity.json So we had to wrap the 404.jsp to catch the exception.

Avatar

Employee

Yes, the call is 404 because it does not exist. It should be:

30/Apr/2020:08:48:57 -0400 [4475] -> GET /conf/global/settings/granite/operations/maintenance/granite_daily.infinity.json HTTP/1.1 30/Apr/2020:08:48:57 -0400 [4475] <- 200 application/json 8ms