-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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-rx-java - Unnecessary wrapping of handlers while invoking setters on delegate #1463
Comments
can you still see that with 3.3.0-SNAPSHOT ? |
Hi @vietj, I still see that in 3.3.0-SNAPSHOT. |
I will try to improve this for this type. Beside the void type do you see any other type it applies to ? I'll ping you when it is updated |
Yes, it seems like Buffer (handler / bodyHandler), AsyncResult(push / sendFile), HttpFrame (customFrameHandler), HttpServerFileUpload (uploadHandler) also have issues. AsyncResult methods also have some logic and thus a simple adapter fix cannot help here. |
for Buffer it is not the same class : io.vertx.core.buffer.Buffer versus io.vertx.rxjava.core.buffer.Buffer
|
btw can you reopen this issue in the correct repository https://github.com/vert-x3/vertx-rx ? |
Created - vert-x3/vertx-rx#42 Got it about the Buffer, but we would need a null check in that case. |
While consuming vertx-rx-java, I see that handlers set on delegate are wrapped objects of input parameters. This seems to pose two issues -
Example:
io.vertx.rxjava.core.http.HttpServerResponse#drainHandler, closeHandler
My use case expects to wait for some data to arrive from an external source and write it to client. I register to drain handler when I have excess amount of data and write queue gets full. When I do not have data to write (as I wait for my source to send some), drain events make no sense and I unregister by setting drain handler to null. Though my overall functionality is not impacted, there are NPEs thrown from vertx and additional objects are created.
The text was updated successfully, but these errors were encountered: