Accessing redirect manager dashboard intermittently renders a 503 #3637
Replies: 2 comments 2 replies
-
|
does it work on localhost:4502? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we haven't observed any issue with reaching it locally. We're on AEMaaCS and the issue is persistent on all of our 3 environments (dev, stage, prod). And were on the latest version that adobe pushes. Unsure of how many redirects that we have, but it's in the range of 6000-8000. We can reach on step further down, i.e. the configuration page of each configuration that we've set up. Which we've structured as one configuration per domain. And we can create/update/delete/publish the redirects without much trouble. The trouble we have is that we don't ge redirected back to the configuration page after clicking "publish", but that is a minor issue. |
Beta Was this translation helpful? Give feedback.
-
|
I should also add that we might have some older dependencies that hasn't been upgraded since the start of our project ~4 years ago.. |
Beta Was this translation helpful? Give feedback.
-
|
Redirects are paginated. How many do you display at a time? Also, back in time all redirects were saved as direct children, e.g. at some point it was changed to a sharded structure, e.g. The simplest way to convert the old structure to the new one is to export the rules into a spreadsheet and import it back. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We've recently upgraded from ACS Commons 6.6.4 to ACS Commons 6.14.0.
After which we begun to observe that the redirect managers dashboard page, renders a 503 most of time. And at some rare occasions the page actually renders properly, but only once until it goes back to not rendering.
Dashboard page path "/apps/acs-commons/content/redirect-manager/redirects.html"
When the dashboard renders properly this is what's in our logs:
And we haven't been able to identify any particular logging related to the 503 request. Only this request in the browser:
We're on the investigation path that this could be related to the last entry. Which seems to blacklist a resource for 300000ms.
Has anyone run into a similar issue or might have an idea where we can look for a probable cause?
We appreciate any help that can be given!
Beta Was this translation helpful? Give feedback.
All reactions