Open parasjain27031994 opened 8 months ago
/cc @mmusgrov (narayana)
The transaction has timed out and the transaction reaper is trying to roll it back but it cannot do that because the owning thread is blocked in doExecutePreparedStatement. We detect that and report it using the code ARJUNA012381 (thread Lambda Thread was in progress with java.base@17.0.9/sun.nio.ch.SocketDispatcher.read0(Native Method)).
The transaction timeout handing thread is internal to the transaction manager so we cannot report it to the application using an exception.
To fix it you should tune your database operations or extend the transaction timeout.
Possible reasons for long running database operations include:
Describe the bug
I have a Quarkus Application deployed as a Native executable on AWS Lambda. For some executions, the lambda time out after being in hung states for 900 seconds.
From the logs I see below traces from transaction manager
The above exceptions were printed as warning and resulted in lambda being in hung state and eventually time out. I am trying understand the cause of failure, however I believe the exception should have been thrown rather than being swallowed so the code could handle the exception in reasonable way.
Expected behavior
Exception should be thrown.
Actual behavior
Exception is swallowed.
How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
17
Quarkus version or git rev
3.5.2
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response