Thanks for following up!

for this information. With this information we’ve now managed to recreate the issue outside the bugfest/hosted reference environments although still not sure we can do this completely reliably. We’re continue to investigate but some information from the dev team:

• running mod-agreements master branch, spinning up 30 tenants with maxpoolsize of 50

• Generally restarting the module when it locks up unblocks things again

• Best theory currently is that there's a missing transaction clause which causes each call to each tenant to open a connection which never closes

  • If this is the cause then would expect 30 tenants to saturate 50 connections after 4 hours (with hourly job runner), however harvests only trigger every other hour, so that would imply 7 tenants would lock up on bugfest after c. 28 hours

  • However, this theory doesn’t obviously explain why simply spinning up tenants can cause a different kind of crash - this needs further investigation

some logs attached from sprint-testing env

current situation and steps to reproduce:

Situation:

mod-agreements and potentially all of the affected module could be deployed and could be enabled for some tenants, if you count number of tenants, which can be enabled with DB_MAXPOOLSIZE='50' it will be something like below:

1. fs09000000

2. fs09000002

3. fs09000003

4. cs00000int

5. cs00000int_0001

6. cs00000int_0002

7. cs00000int_0003

then the next tenants in the list just got stuck and whole update process just failing.

on the Bugfest side we do have 15 tenants, real production clusters have something like 50-60 tenants.

Please support: ,

cc: