Issue #4890 trigger leak analysis #5295
Conversation
reinhapa
force-pushed
the
bugfix/issue4890_restore_memory_leak
branch
from
37ec663
to
16b072b
Compare
|
@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. |
|
@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. |
|
@reinhapa here is the backup to restore The collection where an update trigger is configured is |
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) |
|
They do not get removed after the backup is completed. One needs to restart the instance to get rid of them. |
reinhapa
force-pushed
the
bugfix/issue4890_restore_memory_leak
branch
from
5eef0e2
to
2c5b318
Compare
- Use default 'equals' implementation of record - Store all thread related data within a central concurrent hash map in order to better track potential leaking data
reinhapa
force-pushed
the
bugfix/issue4890_restore_memory_leak
branch
from
474e578
to
1473c21
Compare
|
|
disable triggers -> breaks stuff ? |
|
See: #4890 (comment) |
Analysis and simplifications to tackle the leaking trigger states.