Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARTEMIS-3848 High CPU usage on ReadWriteLocks #4098

Merged
merged 2 commits into from
May 25, 2022

Conversation

clebertsuconic
Copy link
Contributor

This is caused by too many entires on the HashMap for ThreadLocals.
Also: I'm reviewing some readlock usage on the StorageManager to simplify things a little bit.

Copy link
Contributor

@franz1981 franz1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you make use of a thread local without removing the data on it you still risk to leak the artemis thread pool thread it references...
I suggest to give up on re-entrancy and just use a stamped lock, that's rw as well

@clebertsuconic clebertsuconic force-pushed the thread-local branch 2 times, most recently from 3cdd7a6 to 80dd821 Compare May 25, 2022 13:45
@clebertsuconic
Copy link
Contributor Author

@franz1981 it might be an option: however I don't want to break anything else now. I may do that as a major separate task.

localListenersPool.set(null);

// We are reusing a previously created ArrayList for this localArray
ArrayList<ReadyListener> localArrayList = readyListenersPool.get();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@franz1981 I'm changing this code you wrote here. This was also introducing many entires on the ThreadLocal.

@clebertsuconic clebertsuconic force-pushed the thread-local branch 3 times, most recently from 0050b0b to 20d2014 Compare May 25, 2022 14:38
JMSTestCase is deprecated anyway.
in its older form many many years ago a server would be reused over
between tests.

what forced us to make such verification to avoid messages from one test
leaking into the next.

This was because a server startup was expensive many years ago (less
efficient code and the hardware available 10 years ago)

with the current state of things this is not needed as the server will
be started from scratch on every test
This is caused by too many entries on the HashMap for ThreadLocals.
Also: I'm reviewing some readlock usage on the StorageManager to simplify things a little bit.
@clebertsuconic clebertsuconic merged commit a2dd805 into apache:main May 25, 2022
@clebertsuconic clebertsuconic deleted the thread-local branch July 12, 2022 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants