Exposed 1.0.0-rc2, r2dbc with r2dbcpool, the first...

# exposed

[Oğuzhan Soykan]

Exposed 1.0.0-rc2, r2dbc with r2dbcpool, the first database query sometimes hangs even though there is a warm-up at the startup, stack trace is in the thread.
in theory, it is the second database query after warmup. but the request can not complete due to hanging on the repository side.

[Oğuzhan Soykan]

“reactor-tcp-nio-5” #98 [47107] daemon prio=5 os_prio=31 cpu=47.07ms elapsed=99.18s tid=0x0000000c84ced000 nid=47107 waiting on condition [0x000000017657a000]
java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@24.0.2/Native Method)
- parking to wait for <0x0000000430843560> (a kotlinx.coroutines.BlockingCoroutine)
at java.util.concurrent.locks.LockSupport.parkNanos(java.base@24.0.2/LockSupport.java:271)
at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:97)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:70)
at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:48)
at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
at org.jetbrains.exposed.v1.r2dbc.R2dbcDatabase.connectionMetadata$exposed_r2dbc(R2dbcDatabase.kt:58)
at org.jetbrains.exposed.v1.r2dbc.R2dbcDatabase.identifierManager_delegate$lambda$21(R2dbcDatabase.kt:122)
at org.jetbrains.exposed.v1.r2dbc.R2dbcDatabase$$Lambda/0x000000c0016a40c0.invoke(Unknown Source)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)
- locked <0x000000042d88fe20> (a kotlin.SynchronizedLazyImpl)
at org.jetbrains.exposed.v1.r2dbc.R2dbcDatabase.getIdentifierManager(R2dbcDatabase.kt:122)
at org.jetbrains.exposed.v1.core.Transaction.fullIdentity$lambda$4(Transaction.kt:94)
at org.jetbrains.exposed.v1.core.Transaction$$Lambda/0x000000c001c645c8.invoke(Unknown Source)
at org.jetbrains.exposed.v1.core.QueryBuilder.invoke(Expression.kt:19)
at org.jetbrains.exposed.v1.core.Transaction.fullIdentity$exposed_core(Transaction.kt:90)
at org.jetbrains.exposed.v1.core.Column.toQueryBuilder(Column.kt:48)
at org.jetbrains.exposed.v1.core.QueryBuilder.append(Expression.kt:58)
at org.jetbrains.exposed.v1.core.QueryBuilder.unaryPlus(Expression.kt:67)
at org.jetbrains.exposed.v1.core.AbstractQuery.prepareSQL$lambda$25$lambda$18(AbstractQuery.kt:231)
at org.jetbrains.exposed.v1.core.AbstractQuery$$Lambda/0x000000c001c64398.invoke(Unknown Source)
at org.jetbrains.exposed.v1.core.QueryBuilder.appendTo(Expression.kt:31)
at org.jetbrains.exposed.v1.core.QueryBuilder.appendTo$default(Expression.kt:22)
at org.jetbrains.exposed.v1.core.AbstractQuery.prepareSQL$lambda$25(AbstractQuery.kt:231)
at org.jetbrains.exposed.v1.core.AbstractQuery$$Lambda/0x000000c001c63d00.invoke(Unknown Source)
at org.jetbrains.exposed.v1.core.QueryBuilder.invoke(Expression.kt:19)
at org.jetbrains.exposed.v1.core.AbstractQuery.prepareSQL(AbstractQuery.kt:209)
at org.jetbrains.exposed.v1.core.AbstractQuery.arguments(AbstractQuery.kt:81)
at org.jetbrains.exposed.v1.core.AbstractQuery.arguments(AbstractQuery.kt:10)
at org.jetbrains.exposed.v1.r2dbc.statements.SuspendExecutableKt.executeIn(SuspendExecutable.kt:122)
at org.jetbrains.exposed.v1.r2dbc.R2dbcTransaction.exec(R2dbcTransaction.kt:230)
at org.jetbrains.exposed.v1.r2dbc.R2dbcTransaction.execQuery(R2dbcTransaction.kt:283)
at org.jetbrains.exposed.v1.r2dbc.R2dbcTransaction.execQuery$exposed_r2dbc(R2dbcTransaction.kt:287)
at org.jetbrains.exposed.v1.r2dbc.Query.collect$suspendImpl(Query.kt:316)
at org.jetbrains.exposed.v1.r2dbc.Query.collect(Query.kt)

[Oğuzhan Soykan]

I would expect at least cancel the query or timeout but it seems the query does not trigger any timeout, since connectionMetadata hangs

R2dbcDatabase:

internal fun <T> connectionMetadata(body: R2dbcExposedDatabaseMetadata.() -> T): T = runBlocking { metadata(body) }

[Oğuzhan Soykan]

@Oleg Babichev, I am investigating the possibilities where the problem can be located, would you happen to have any tips to dig this further?

[Oleg Babichev]

Thank you for mentioning the issue, the version 1.0.0-rc-3 was published, and it contains several fixes for transactions management (and actually complete refactoring for jdbc transaction management) that fixed several issues related to thread switching in suspend transactions execution. Could you check your code on that version, ping me if the problem will still exist.