[WIP] Add interfaces for refactoring work #1276
Conversation
Qodana Community for JVM1 new problem were found
💡 Qodana analysis was run in the pull request mode: only the changed files were checked View the detailed Qodana reportTo be able to view the detailed Qodana report, you can either:
To get - name: 'Qodana Scan'
uses: JetBrains/[email protected]
with:
upload-result: trueContact Qodana teamContact us at [email protected]
|
aaron-congo
force-pushed
the
refactoring-wip
branch
from
184b68a to
528af13
Compare
aaron-congo
force-pushed
the
refactoring-wip
branch
from
528af13 to
9ebeb8a
Compare
wrapper/src/main/java/software/amazon/jdbc/util/StorageService.java
Outdated
Show resolved
Hide resolved
wrapper/src/main/java/software/amazon/jdbc/util/events/EventPublisher.java
Outdated
Show resolved
Hide resolved
|
|
||
| package software.amazon.jdbc.util.monitoring; | ||
|
|
||
| public enum MonitorState { |
There was a problem hiding this comment.
Does that indicate a monitor that has been instantiated but never run? With the current design the monitor service doesn't provide a method to submit a monitor without running it, we just have the "runIfAbsent" method which would automatically create and run the monitor. So I'm not sure if we'd ever have a monitor in this state.
There was a problem hiding this comment.
Theoretically it's possible to create an instance, add it to the list of monitors and let other threads to observe it. In this case the monitor is created but isn't yet started. Otherwise your code has to guarantee that such monitors won't be available for other observers.
There was a problem hiding this comment.
Currently the API doesn't have a method that creates a monitor but does not run it. The only way to submit a monitor is to call the runIfAbsent method which will automatically start the monitor when it is created. If we discover we need a method that submits a monitor but does not start then yes we should add this state.
wrapper/src/main/java/software/amazon/jdbc/util/monitoring/MonitorStatus.java
Outdated
Show resolved
Hide resolved
|
|
||
| void stop(); | ||
|
|
||
| MonitorStatus getStatus(); |
There was a problem hiding this comment.
There's an exception as part of MonitorStatus. Is it an unhandled exception that stops/breaks a monitor?
There was a problem hiding this comment.
That was my intention yes, it would be a reference to an exception that caused a monitor to unexpectedly stop.
There was a problem hiding this comment.
That means it's a handled exception (since it's been caught and stored). That contradicts the original goal. It's possible that monitor isn't able to catch it so monitor service needs to handle them.
There was a problem hiding this comment.
Oh, I was thinking the monitor would use a try-catch for its entire run loop that would catch the generic Exception type (eg it would catch any unhandled exceptions) and then it would set its exception status. So the monitor itself would be responsible for indicating it has hit an unexpected error, and the monitor service's watcher thread would check the monitor's status to see if it has hit an error. Do we want to pursue a different approach?
| * @param subscriber the subscriber to be notified when the given event classes occur. | ||
| * @param eventClasses the classes of event that the subscriber should be notified of. | ||
| */ | ||
| void subscribe(EventSubscriber subscriber, Class<?>... eventClasses); |
There was a problem hiding this comment.
When I make this change I get the warning "Possible heap pollution from parameterized vararg type", so maybe I'll make this a Set<Class<? extends Event>> instead of a vararg
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.