[OPENAM-5864] Quota constraints exceeded in multi-instance with LB and CTS enabled Created: 21/Apr/15 Updated: 06/Oct/17 Resolved: 06/Oct/17
|Affects Version/s:||11.0.2, 12.0.2, 13.0.0|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Sprint:||AM Sustaining Sprint 15|
|Support Ticket IDs:|
2 OpenAM 11.0.2 instances behind HA_Proxy
A simple curl that throws the same authentication request for the same user; loop 5000 times:
In the Session log file, you can see that the number of sessions is being checked in order to decide whether the quota has been reached. At the beginning of the logs I can see it stays at 2 existing sessions - as it should -, then it moves on to 3 and does not go back down.
|Comment by Simon Harding [ 28/Apr/16 ]|
Also observed on AM 12.0.2 and AM 13.0.0 using both single AM instance (all embedded DJ) and multiple instance (all embedded and with an external CTS).
Concurrent attempts to authenticate are not subject to quota constraints. For example, quota constrainsts turned on with DESTROY_LAST works correctly with no concurrency:
But allows extra sessions to be created with concurrency:
Also observed using concurrently executed bash scripts consisting of curl commands in a while loop.
|Comment by Robert Wapshott [ 30/Jan/17 ]|
Confirmed, we are able to reproduce an issue which looks highly related to the described issue:
The Apache Bench command then can demonstrate this.
Will leave the server with only two sessions for the demo user.
However moving to multiple concurrency:
We can see that there are now more than two sessions for the demo user in the sessions tab.
The current working hypothesis is as follows: there is a concurrency bug in the DestroyNextExpiringAction class which is not aware of the number of sessions to destroy and so will not consistently destroy them.
|Comment by Andy Hall [ 06/Oct/17 ]|
This was fixed in the linked issue.