Uh oh!
There was an error while loading. Please reload this page.
Fix lookup server connector background jobs problem - #15143
Conversation
blizzz
commented
Apr 18, 2019
Hooks should not be fired if there was no change. But then, if every change lead to a new background job being created (and with the double-triggering you fixed on in another PR) 3 changes might be possible. Email, Displayname for sure, then perhaps avatar and/or quota. |
rullzer
left a comment
There was a problem hiding this comment.
Didn't test in dept but makes sense
Uh oh!
There was an error while loading. Please reload this page.
kesselb
commented
May 9, 2019
Could you rebase? 🤔 |
ff8dbf7 to
a5c52bcComparerullzer
commented
May 11, 2019
@kesselb rebase happend. review? |
nickvergessen
commented
Jul 18, 2019
Still waiting for reviews @MorrisJobke@blizzz@ChristophWurst |
MorrisJobke
commented
Jul 18, 2019
Let me rebase to trigger CI again. |
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
To ensure there is only 1 background job per user Signed-off-by: Joas Schilling <coding@schilljs.com>
a5c52bc to
30051e7CompareMorrisJobke
commented
Jul 18, 2019
@nickvergessen Should we back port this? |
nickvergessen
commented
Jul 18, 2019
In theory it would be cool, but I think its too heavy :/ |
MorrisJobke
commented
Jul 18, 2019
Okay. Then keeping it here. |
Some 50 user instances have 400k pending jobs for lookup updates
The first problem is that the job was scheduled too often with #15020
The second one is that each time any value changed, a new job was scheduled (because at least the retry count and the last execution was different).
So you ended up with 6 jobs per change on user data.
As LDAP seems to set the user name/email some more times, it basically added the 6 jobs on each login?
So now the app got a little update and in the end can only have 1 background job per user.
Existing update requests are killed when the userId is not set in the arguments, so the table should clean up on the next few cron runs after the update.