Connection leak with spring-r2dbc

[mindfn]

r2dbc-mariadb version: 1.1.2
r2dbc-pool: 0.9.0
spring-r2dbc: 5.3.21

When Exchange pushes a msg (not the ending packet) through emit , the sink may be set to the completed state by the subscriber, and if other sql continues to execute on the same connection, it may trigger connection leakage.

The problem was triggered when we tried to execute a count statement within a transaction.

Here is the complete command processing:

#  before execute ServerMessageSubscriber.receiverDemands(12) FluxReceive.receiverDemand(12)
- ServerMessageSubscriber#onRequest
- write validation sql
- read/process [ColumnCountPacket]         # after current step ServerMessageSubscriber.receiverDemands(11) FluxReceive.receiverDemand(11)
- ServerMessageSubscriber#onRequest
- read/process [ColumnDefinitionPacket]    # after current step ServerMessageSubscriber.receiverDemands(10) FluxReceive.receiverDemand(10)
- ServerMessageSubscriber#onRequest
- read/process [EofPacket]                 # after current step ServerMessageSubscriber.receiverDemands(9) FluxReceive.receiverDemand(9) 
- ServerMessageSubscriber#onRequest
- read/process [RowPacket]                 # after current step ServerMessageSubscriber.receiverDemands(8) FluxReceive.receiverDemand(8)
- ServerMessageSubscriber#onRequest
- read/process [EofPacket]                 # after current step ServerMessageSubscriber.receiverDemands(7) FluxReceive.receiverDemand(7)
- ServerMessageSubscriber#onRequest
- WRITE 'SET autocommit=1'
- read/process [OkPacket]                  # after current step ServerMessageSubscriber.receiverDemands(6) FluxReceive.receiverDemand(6)
- WRITE 'BEGIN'
- ServerMessageSubscriber#onRequest
- read/process [OkPacket]                  # after current step ServerMessageSubscriber.receiverDemands(5) FluxReceive.receiverDemand(5)
- ServerMessageSubscriber#onRequest
- WRITE 'COUNT SQL'
- read/process [ColumnCountPacket]         # after current step ServerMessageSubscriber.receiverDemands(4) FluxReceive.receiverDemand(4)
- ServerMessageSubscriber#onRequest
- read/process [ColumnDefinitionPacket]    # after current step ServerMessageSubscriber.receiverDemands(3) FluxReceive.receiverDemand(3)
- ServerMessageSubscriber#onRequest
- read/process [EofPacket]                 # after current step ServerMessageSubscriber.receiverDemands(2) FluxReceive.receiverDemand(2)
- ServerMessageSubscriber#onRequest
- read/process [RowPacket]                 # after current step ServerMessageSubscriber.receiverDemands(1) FluxReceive.receiverDemand(1)
- ServerMessageSubscriber#onRequest  
- WRITE 'COMMIT'
- read/process [EofPacket]                 # after current step ServerMessageSubscriber.receiverDemands(0) FluxReceive.receiverDemand(0)
- read/process [OkPacket]                  # OkPacket will be discarded because FluxReceive.receiverDemand is 0
- ServerMessageSubscriber#onRequest        # not execute
- WRITE 'SET autocommit=1'                 # not execute
- read/process [OkPacket]                  # not execute

We use the DatabaseClient from spring-r2dbc to execute the query ,and spring-tx to manager tx, it only gets the first [RowPacket] internally as the query result, and immediately triggers onComplete, which triggers a transaction's COMMIT.

The COMMIT is executed before the [EofPacket] has been processed. After that, two consecutive packets need to be processed, but the FluxReceve.receiverDemand is not updated.

So the [OKPacket ] of COMMIT is discarded, causing the connection not to be released from the connection pool, a connection leak has occurred.

I made the following changes to prevent this problem from happening .

protected class ServerMessageSubscriber implements CoreSubscriber<ByteBuf> {

    @Override
        public void onNext(ByteBuf message) {
              //
                if (srvMsg.ending()) {
                    exchangeQueue.poll();
                    requestQueueFilling();    //To prevent connection leak
                }  
         }
}

Is there any other more appropriate way to prevent this problem from happening?
@rusher

Thanks.

[kidar2]

Hi. We have the problem with connections too, in logs we see the error message "Connection is close. Cannot send anything".

r2dbc-mariadb version: 1.1.2
r2dbc-pool: 0.9.0

@mindfn Are these related issues?

[mindfn]

Hi. We have the problem with connections too, in logs we see the error message "Connection is close. Cannot send anything".

r2dbc-mariadb version: 1.1.2 r2dbc-pool: 0.9.0

@mindfn Are these related issues?

I'm not sure, "Connection closed" occurs in many scenarios.
I recommend checking the relevant connection configuration first;
For example, make sure your connection release time is less than the MySQL physical connection release time，Use "Remote" validation

[rusher]

problem reproduced.

[rusher]

not sure that is related to other cases describe there, but initial issue correction is available using SNAPSHOT release :

<repositories>
    <repository>
        <id>sonatype-nexus-snapshots</id>
        <name>Sonatype Nexus Snapshots</name>
        <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>org.mariadb</groupId>
        <artifactId>r2dbc-mariadb</artifactId>
        <version>1.1.3-SNAPSHOT</version>
    </dependency>
</dependencies>

[mindfn]

Thank you. It seems to work, we will update to the latest version to verify.