gnodet commented on code in PR #24488:
URL: https://github.com/apache/camel/pull/24488#discussion_r3536912238
##########
core/camel-console/src/main/java/org/apache/camel/impl/console/JfrMemoryLeakDevConsole.java:
##########
@@ -137,7 +137,11 @@ private synchronized JsonObject doStart(Map<String,
Object> options) {
// trigger GC before starting to establish a cleaner baseline
System.gc();
try {
- Thread.sleep(500);
+ long deadline = System.currentTimeMillis() + 500;
+ long remaining;
+ while ((remaining = deadline - System.currentTimeMillis()) >
0) {
+ wait(remaining);
+ }
Review Comment:
Good catch — switched to a private `gcWaitMonitor` object so `wait()` does
not release the `this` monitor. The `synchronized(gcWaitMonitor) {
gcWaitMonitor.wait(remaining); }` pattern keeps the outer `this` lock held
(preserving mutual exclusion for recording state) while using `wait()` instead
of `Thread.sleep()` to satisfy S2276. Fixed in 4cbfa57.
_Claude Code on behalf of gnodet_
##########
core/camel-console/src/main/java/org/apache/camel/impl/console/JfrMemoryLeakDevConsole.java:
##########
@@ -202,7 +206,11 @@ private synchronized JsonObject
doStopRecordingAndParse(int limit) {
// trigger GC before stopping to flush objects into the recording
System.gc();
try {
- Thread.sleep(500);
+ long deadline = System.currentTimeMillis() + 500;
+ long remaining;
+ while ((remaining = deadline - System.currentTimeMillis()) >
0) {
+ wait(remaining);
+ }
Review Comment:
Same fix as above — using a private `gcWaitMonitor` object to avoid
releasing the `this` monitor. Fixed in 4cbfa57.
_Claude Code on behalf of gnodet_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
