Issue #4890 trigger leak analysis

[reinhapa]

Analysis and simplifications to tackle the leaking trigger states.

[reinhapa]

@line-o I did some clean ups in preparation for looking into the actual leak. As soon I got your minimal restore example, I try to setup a according test, that may show the issue and can be used to reproduce.

[adamretter]

@reinhapa can you tell me a little about your thinking around removing the ThreadLocal please?

[reinhapa]

@reinhapa can you tell me a little about your thinking around removing the ThreadLocal please?

It's to get more easy access to all currently known per-thread entries in order to find the actual leak behaviour as those can be found more easy as within the thread local variable. It's not intended to stay that way when I got to the actual ground of the problem.

[line-o]

@reinhapa here is the backup to restore full-backup-restore-with-triggers.zip

The collection where an update trigger is configured is /db/apps/restore-with-trigger-test

[adamretter]

to find the actual leak behaviour

What is the leak that you are mentioning? is there a GitHub issue for this I can take a look at?

[reinhapa]

What is the leak that you are mentioning? is there a GitHub issue for this I can take a look at?

@adamretter its issue #4890 where trigger state objects accumulate and only released after the full backup is complete (as I understand @line-o)

[line-o]

They do not get removed after the backup is completed. One needs to restart the instance to get rid of them.

[sonarqubecloud[bot]]

Quality Gate failed

Failed conditions
1 Security Hotspot
51.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[dizzzz]

disable triggers -> breaks stuff ?

[adamretter]

See: https://github.com/eXist-db/exist/issues/4890#issuecomment-2314672530