-
Notifications
You must be signed in to change notification settings - Fork 47
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
Testing futures #1129
Testing futures #1129
Conversation
@@ -298,16 +298,11 @@ private <F extends FilterResult> F handleFilteringException(Throwable t, Decoded | |||
|
|||
private <F extends FilterResult> CompletableFuture<F> handleDeferredStage(DecodedFrame<?, ?> decodedFrame, CompletableFuture<F> future) { |
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.
decodedFrame
is currently redundant in this PR as it was only passed in to work out if it was a request or response for logging purposes.
I'm conflicted about the removal of the logging.
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.
AS discussed in slack, we've standardised on the logging level and will used the same message as the exception for logging. I've kept the usage of decodedFrame
as I think it provides a better message
var timeoutFuture = executorService.schedule(() -> { | ||
final String message; | ||
try { | ||
message = exceptionMessageGenerator.call(); |
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.
I also wonder if we should be passing in a metric to increment here as well (If only we had optional args ala Kotlin...)
1e18251
to
722b18c
Compare
Does this supercede #1125? We're now setting up cancellation for both usages of scheduled timeouts. The PR name/description makes it sound like refactoring only. |
kroxylicious-runtime/src/test/java/io/kroxylicious/proxy/internal/PromiseFactoryTest.java
Outdated
Show resolved
Hide resolved
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.
A few minor comments, but I think the overall direction looks good.
kroxylicious-runtime/src/main/java/io/kroxylicious/proxy/internal/PromiseFactory.java
Outdated
Show resolved
Hide resolved
private final TimeUnit timeoutUnit; | ||
private final Logger logger; | ||
|
||
public PromiseFactory(ScheduledExecutorService executorService, long timeout, TimeUnit timeoutUnit, String loggerName) { |
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 passing the logger name, rather than the logger itself?
- Is it the case that we want the
timeout
to be scoped to the factory, rather than per-promise? In more sophisticated uses you might want to define a timeout that applies over a sequence of timeoutable actions, so you need to compute the remaining timeout and supply that for each subsequent action.
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.
I passed the name rather than the logger as I can't think of another example where I've seen loggers passed around so it felt less surprising, happy to be persuaded otherwise.
Current usage calls for a factory wide logger so that's all I did for now, I also wasn't convinced by the api of passing the logger at the calls. Again happy to be persuaded otherwise.
I'm not sure we have use cases yet for request processing limits or global timeouts. Id rather refactor this when we do than try and design for a problem we don't have now.
kroxylicious-runtime/src/main/java/io/kroxylicious/proxy/internal/PromiseFactory.java
Show resolved
Hide resolved
kroxylicious-runtime/src/main/java/io/kroxylicious/proxy/internal/FilterHandler.java
Outdated
Show resolved
Hide resolved
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
…bout timeouts. rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
To enable testing rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
c0c4ae9
to
b97f841
Compare
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
rh-pre-commit.version: 2.0.1 rh-pre-commit.check-secrets: ENABLED
Quality Gate passedIssues Measures |
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.
LGTM
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.
Thanks @SamBarker
Type of change
Description
Extract a promise factory so that we can apply better testing around timeouts (and potentially other common behaviours in future)
Additional Context
Checklist
Please go through this checklist and make sure all applicable tasks have been done