Assuming the database limit for user connections is set ("-n 50"), is there a way to get PASOE to honor that limit as well in some way as well?
When the PASOE sesion manager is launching new ABL sessions, and those sessions fail to connect to a database via client/server, then the PASOE session manager doesn't back off in any way. Instead, PASOE makes the problem even worse by rapidly attempting to create even more ABL sessions. It also introduces its own internal bugs into the mix, leaving HTTP session in tomcat open that need to be cleaned up manually.
I'm hoping someone has come up with a strategy to allow PASOE and the database to play more nicely together. If the database hits a limit (like -n) and it disallows new connections then the default behavior of PASOE just makes the problem even worse.
Ideally PASOE would have some basic awareness of what an OE database is, and what the symptoms are when an OE database is not available for new connections. Then it might be able to give us better error messages and possibly better recourse upon failure (ie. in the very least it should avoid rapid retries when the database is already swamped).
I have more details about this problem here. https://community.progress.com/community_groups/openedge_development/f/19/t/61796
I'm hoping the PASOE resource limits can take database limits into account. I'm also hoping we aren't the first to encounter the problems but I haven't found that many search results for this issue.
The good news is we just delivered this feature in OpenEdge 12.2. While it is important that you understand how many database connections your server will need based on how many sessions you have configured, the fact is other DB clients can take those away.
To solve this problem, we have just introduced the PASOE Agent Self Management feature. This feature allows you to set how many available sessions should be available in an agent process. The default is 1. It works this way:
The agent will ensure there is minAvailableSessions in an agent that is not servicing requests. If you have your maxSessions and numConnections set to 100, Sessions will be created as load increases. If you have 50 concurrent sessions servicing requests, the agent will have created an extra session that is available, so you will be at 51 actual sessions. As load continues to increase and you run out of database connections, eventually these spare sessions will be unable to be created. Let's say this happens at 75 sessions and the failure happens while trying to create session 76. Since this session is not servicing a request, no client will see the error. When the agent sees this, it will reduce the maxABLSessions down to 75, and will no longer attempt to create a session that fails.
When dealing with multiple agents, it is important that they all be started initially with at least a single session. We found out late that if you are using this feature and the session manager attempts to start a new agent, that agent will fail due to its inability to create a single session. Since this feature is implemented in the agent itself, the session manager is currently unaware that it shouldn't be starting a new agent. We may address this in a future release, as well as anything else we get feedback on related to this feature.
I expect we will be updating the tuning guide in the coming months to include this feature. Let me know if you have any questions on this feature,
Dave
The good news is we just delivered this feature in OpenEdge 12.2. While it is important that you understand how many database connections your server will need based on how many sessions you have configured, the fact is other DB clients can take those away.
To solve this problem, we have just introduced the PASOE Agent Self Management feature. This feature allows you to set how many available sessions should be available in an agent process. The default is 1. It works this way:
The agent will ensure there is minAvailableSessions in an agent that is not servicing requests. If you have your maxSessions and numConnections set to 100, Sessions will be created as load increases. If you have 50 concurrent sessions servicing requests, the agent will have created an extra session that is available, so you will be at 51 actual sessions. As load continues to increase and you run out of database connections, eventually these spare sessions will be unable to be created. Let's say this happens at 75 sessions and the failure happens while trying to create session 76. Since this session is not servicing a request, no client will see the error. When the agent sees this, it will reduce the maxABLSessions down to 75, and will no longer attempt to create a session that fails.
When dealing with multiple agents, it is important that they all be started initially with at least a single session. We found out late that if you are using this feature and the session manager attempts to start a new agent, that agent will fail due to its inability to create a single session. Since this feature is implemented in the agent itself, the session manager is currently unaware that it shouldn't be starting a new agent. We may address this in a future release, as well as anything else we get feedback on related to this feature.
I expect we will be updating the tuning guide in the coming months to include this feature. Let me know if you have any questions on this feature,
Dave
This will be helpful. I look forward to upgrading.
I will reply on the other thread about the session-manager issues in OE 11.7.x.