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

vertx: end responses safely #3165

Merged
merged 4 commits into from
Sep 23, 2023
Merged

vertx: end responses safely #3165

merged 4 commits into from
Sep 23, 2023

Conversation

michael72
Copy link

this is regarding my issue #3157

The consequence of these changes is that (at least for VertxFutureServerInterpreter) the exception java.lang.IllegalStateException: Response has already been written does not occur any more.

The question is if the other changes are - maybe a bit too much?
One thing about the logging: I added slf4j logging because vertx logger should not be used directly.
See: eclipse-vertx/vert.x#2774

@kciesielski
Copy link
Member

@michael72 thanks a lot for this fix! I am not sure about hardwiring to slf4j. What if we leave the logging entirely? There are 2 usages:

  1. Error logging on catching Throwable in safeEndWait - is it ok to swallow the exception here? What if it just falls through? Or was the original problem in the first place?
  2. In handleError, as an additional operation - wouldn't rc.fail(ex) cause some kind of logged error on another level?

Another minor thing is the hardcoded duration for safeEndWait. It is a default value which cannot be overridden be the user anyway. Maybe it should be read from VertxServerOptions (and set to a default value there)?

- address reviewer comments: remove slf4j dependency
- add 2 seconds max wait time to VertxServerOptions
@michael72
Copy link
Author

@kciesielski

Thanks for the review!

  • safeEndWait -> just letting the exception through is probably the better option. It wasn't the problem in the first place, but simply ignoring the future looked a bit dubious here and could have lead to some problems
  • rc.fail seems like does not invoke an extra logging, but it will trigger failure or error handlers - and they may or may not do logging. The handling here was also partly doing logging and partly not. Seems like there wasn't a real convention here.

btw it looks like debugLog and infoLog are not used anywhere in the code and they both use the deprecated api - hm.

@adamw
Copy link
Member

adamw commented Sep 19, 2023

@michael72 The Await was troubling me a bit, so I took a shot at actually changing the implementation so that it returns a vertx Future, and then converting it to the effect type. That way ZIO/cats should wait with the effect completion until the response is written. Also in case when the response is already ended, I'm returning an already completed future so that things don' tblock. Take a look and let me know if this makes sense :)

@michael72
Copy link
Author

@adamw I think this looks good! I cannot say much about the zio/cats stuff though.
Cheers!

@adamw adamw merged commit 977f331 into softwaremill:master Sep 23, 2023
@adamw
Copy link
Member

adamw commented Sep 23, 2023

Good, let's try then ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants