-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-27968 add JvmPauseMonitor in hbase-client #5319
base: master
Are you sure you want to change the base?
Conversation
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also add it for ConnectionImplementation
?
@@ -121,6 +122,8 @@ public class AsyncConnectionImpl implements AsyncConnection { | |||
private final String metricsScope; | |||
private final Optional<MetricsConnection> metrics; | |||
|
|||
private JvmPauseMonitor pauseMonitor; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this a singleton, instead? In the case of applications opening or pooling multiple connections, we don't need a separate JvmPauseMonitor per connection, just a single one for the whole application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea ! But if so, we may need to consider adding a reference count to pauseMonitor. Only when all connections that refer to it are no longer active, we can stop it . Or we can keep it all the time , even all the connections are closed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think we don't need to stop it when connection is closed, it may be useful to have it running for as long the client application runs.
Thanks for the review @wchevreuil Sorry, I didn't find the |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
private JvmPauseMonitorSource metricsSource; | ||
private final JvmPauseMonitorSource metricsSource; | ||
|
||
public static synchronized JvmPauseMonitor getInstance(Configuration conf) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change it to singleton? What if we pass different Configuration here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two reasons.
@wchevreuil mentioned that our user may open multiple connections, however only one pause monitor is enough for a process. More details please see here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we only want one JvmPauseMonitor in process, then we should not bind it to a connection? Just add a utility method to enable jvm pause monitor is enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Let me try to fix this. Thanks Duo ! @Apache9
Yeah, you are right. My bad, I was looking at older branches. LGTM, assuming the UT failures are unrelated. |
No description provided.