You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, in order to accommodate the fact the JDBC Message Store uses a UUID representation of the group Id, the ACMH has to use the UUIDConverter to obtain the id of the lock for the group.
This is because the reaper only has the UUID, and not the original group key (correlation id).
When refactoring the JDBC message store to retain the original group key, ensure that the ACMH is also changed, to gain the optimization.
I wonder if that's still on the roadmap. Using the UUIDConverter all over the place is also bad for performance reasons:
When not passing in a UUID, every time it internally throws an exception to detect invalid UUIDs.
Creating stack traces is an expensive operation to do.
Gary Russell opened INT-2758 and commented
Currently, in order to accommodate the fact the JDBC Message Store uses a UUID representation of the group Id, the ACMH has to use the UUIDConverter to obtain the id of the lock for the group.
This is because the reaper only has the UUID, and not the original group key (correlation id).
When refactoring the JDBC message store to retain the original group key, ensure that the ACMH is also changed, to gain the optimization.
This issue is a sub-task of #6647
Issue Links:
The text was updated successfully, but these errors were encountered: