-
Bug
-
Resolution: Fixed
-
Blocker
-
3.5.3
-
None
Ok, this is pretty difficult to explain since the principal cause is still unknown but I saw it several times...
I will try to trace the root issue separately, but here I will discuss only a fix that can alleviate the problem.
Happened only on a clustered instance with a jackrabbit bundle db persistence manager on ms sql server (since magnolia 3.1 milestones to 3.5.3):
- on one of the nodes magnolia can't find the anonymous user at startup also if it should be there (this is the problem that still needs to be investigated)
- ... so it creates a new Anonymous user with default permissions (none)
- the new anonymous user gets propagated to othe instances
- other calls still can't find such user, so more anonymous users are created
- the result is that at the end there are hundreds of anonymous users in the repository (all of them called "anonymous")
- all the cluster nodes gets locked up (public instances starts to show the magnolia login page!)
the only way to restore it is to shut down all the instances, restart only one of the, log into magnolia as a superuser and delete manually all the additional "anonymous" users.
I am debugging this problem, but I don't still have any clue on why the anonymous user couldn't be found. Looks like a jackrabbit bug but it's really strange.
Anyway, since the scenario after the initial problem is so bad, I think we should at least avoid that magnolia could cause such damage, by NOT creating the anonymous user anymore if it can't find it. Note that this happened several times and that only the anonymous user looks to be affected.