Random IllegalReferenceCountException: refCnt: 0
#245
Comments
|
This looks as if the connection was disconnected earlier on and still some activity happens later on. The |
|
I haven't seen anything, waiting for another fail to check again |
|
I'm getting a similar but not predictably repeatable error, which might be the same problem: My stack is: The stack trace doesn't touch my code so I can't prove what function is triggering it. However, I think it is due to reading from a Blob object as when I comment out the Blob reading code it never triggers. val buffer = ByteBuffer.allocate(65536)
blobObject.stream().collect<ByteBuffer>(buffer::put)Note: I am caching the result of the above code as Blobs can only be read once. I have no reason to believe that a second thread/co-routine might be trying to read before the result is cached. From io/r2dbc/spi/Blob.java /**
* Returns the content stream as a {@link Publisher} emitting {@link ByteBuffer} chunks.
* <p>
* The content stream can be consumed ("subscribed to") only once. Subsequent consumptions result in a {@link IllegalStateException}.
* <p>
* Once {@link Publisher#subscribe(Subscriber) subscribed}, {@link Subscription#cancel() canceling} the subscription releases resources associated with this {@link Blob}.
*
* @return a {@link Publisher} emitting {@link ByteBuffer} chunks.
*/
Publisher<ByteBuffer> stream();I suspect that |
|
The issue is still there: |
|
Hi everybody! Reporting that we are facing possibly the same problem and also the memory leak notification from Netty leak detector. In our use case we are using r2dbc, r2dbc-pool, Reactor, Spring and we are connecting to MS SQL Server. Leak nag: Stack trace regarding refCnt: |
|
Hi all! I believe this problem would be corrected by moving Please confirm. |
mp911de
added a commit
that referenced
this issue
Nov 20, 2023
…response handlers. Terminating the request queue will ensure that no new requests will be accepted and thus that we could miss a response handler to be terminated. [#245] Signed-off-by: Mark Paluch <[email protected]>
mp911de
added a commit
that referenced
this issue
Nov 20, 2023
…response handlers. Terminating the request queue will ensure that no new requests will be accepted and thus that we could miss a response handler to be terminated. [#245] Signed-off-by: Mark Paluch <[email protected]>
mp911de
added a commit
that referenced
this issue
Nov 20, 2023
…response handlers. Terminating the request queue will ensure that no new requests will be accepted and thus that we could miss a response handler to be terminated. [#245] Signed-off-by: Mark Paluch <[email protected]>
|
Changing order will complete the request queue first and then discard the pending response handlers. It will guarantee that no new request will be accepted and I think, that is a useful change. I'm not sure whether it will fix the issue though. Snapshot builds are available now, please retest. |
Thanks, I did test this with my custom snapshot that I built locally and the I will test with your snapshot as soon as possible! Thanks again! |
I think this is actually an improvement. Connection closed can happen when there is too much pressure on the connection (i.e. server TCP recv buffers exhausted). Can you check how much activity is going on, especially parallel activity? Switching to concatMap instead of using flatMap or large prefetch sizes should get you there. Once I get the confirmation from your side that the fix is appropriate, I'll close the ticket here. |
|
Bad news: I attempted my use case with Good news: I could not see the For me, the error is the following (real parameter names renamed): BUT, the query in question does not even specify the I will comment this also to #276. We are using 1.0.0.RELEASE in our released solution at the moment. |
|
Thanks a lot for confirming. Closing this one as done. The other issues are different ones that we need to sort out. |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a randomly failing test on Github Actions, unfortunately, no steps to reproduce.
Versions
The text was updated successfully, but these errors were encountered: