-
Notifications
You must be signed in to change notification settings - Fork 1.1k
java.lang.NullPointerException: Cannot invoke "org.reactivestreams.Subscription.cancel()" because "this.upstream" is null #11643
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
Comments
Are there any tips or tricks on reproducing issues with reactive streams? From the stack trace it seems like something is getting cancelled, and while being cancelled it's hitting the NPE. It seems like we'd need to know what's cancelling it, but I have no idea how to find that. |
Based on the stack trace it looks like this is happening when an HttpClient call is being completed. On one service (so far) we've narrowed it down to a JWKS refresh. By changing the JWKS cache expiration the errors went way down, possibly to zero. That particular service doesn't use HttpClient for anything else, so we'll verify with another service and let you know. |
Also noticed this seems to correlate with
But that could be a coincidence. Just noting it for now. |
Lengthening the JWKS cache expiration did mitigate but not completely eliminate the problem. So far we have not found a way to replicate the issue. Since the only impact appears to be some extra logs entries, and the number of log entries is mitigated by increasing the cache expiration, we're considering this to be more of a nuisance than a critical issue. |
Switching to CacheableJwkSetFetcher completely eliminated the error, so the error is somehow tied to ReactorCacheJwkSetFetcher. Seeing how ReactorCacheJwkSetFetcher is deprecated, is there still a chance this bug could get fixed? On a side note, JwksCacheConfigurationExistsCondition only checks for a Caffeine cache. It would be nice if it would find any kind of cache (such as Redis). We had to pull in Caffeine just for this. |
FYI we got Redis working. Had to implement a JwkSetFetcher like CacheableJwkSetFetcher, but checking for the redis cache property. Had to put it in the same package since we had to use the package-private |
Looks like a reactor bug tbh. I don't see a way in which that NPE could happen through misbehavior on our side |
I'm putting this on hiatus unless someone can provide a reproducer. |
Seeing this new error after upgrading to Micronaut 4.7.6 from 4.6.3. It doesn't seem to cause any problems in the API, just fills up the logs. Two services upgraded so far, and both are seeing the issue-- though one only saw it once and the other 512 times.
Expected Behavior
No NullPointerException should be thrown
Actual Behaviour
Seeing this error in the logs: "Operator called default onErrorDropped" with the following stacktrace:
Thread is a Netty event loop thread, for example
default-nioEventLoopGroup-5-3
.Logger is
reactor.core.publisher.Operators
.Steps To Reproduce
Not sure yet. Might be load related? Will give more info when we have it. Wanted to post this in case someone else is working the same issue already.
Environment Information
No response
Example Application
No response
Version
4.7.6
The text was updated successfully, but these errors were encountered: