Loading...
Loading...
A transaction that triggers a long running query that does not complete within 4 hours may encounter a "Read timed out" exception. The query may then be left running on the database while the transaction continues with the next steps / completes / is cancelled. Please note that if there is Read Replica configured for the instance and if the long running query was running on a read replica, the platform will re-attempt the same query on the Primary database. A second "Read timed out" exception may be thrown if the query does not complete after 4 hours. The impact of the long running queries would be high history list length and increased database contention which may then lead to a delay in execution of jobs, updateset commits and/or performance degradation. Steps to Reproduce 1. Trigger a long running query from Scripts - Background or job. 2. In the localhost logs for the job/transaction, you will see a "Read timed out" exception similar to the one below that will be thrown if the query is running for more than 4 hours. 2023-01-27 16:14:19 (541) worker.1 worker.1 txid=465541d71bac WARNING *** WARNING *** Connection exception encountered, revalidating pool: (conn=1086331) Read timed out 2023-01-27 16:14:19 (541) worker.1 worker.1 txid=465541d71bac WARNING *** WARNING *** (conn=1086331) Read timed out java.sql.SQLNonTransientConnectionException: (conn=1086331) Read timed out at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:234) at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:165) at org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:238) at org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:355) at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:406) at jdk.internal.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 3. The query will still be running on the database though the transaction has progressed/completed/cancelled.
This problem is targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available. Contact SN Technical Support to terminate the long running queries left on the database to prevent further impact. The sys_trigger table may need to be rebuilt to provide relief for the delay of jobs (if the source of the query is from a scheduler worker). SN Support will also review the query to see if the response time can be improved via an index hint or additional indexes. As a common source of the long running query is from a custom job / script or configuration, review the configuration / query for the common causes below: the filter criteria are on fields that are not indexed and/or on large field types such as String (8000) the query has a large number of OR conditions and refactor the query to: include filter criteria on indexed fields (especially if the query involves multiple joins to large tables) split the query into multiple queries to reduce the dataset returned and/or avoid multiple OR conditions avoid using CONTAINS operator (consider using STARTSWITH instead) consider using strategies such as time boxing the query using datetime fields that are indexed such as Created on to reduce the dataset (Performance Best Practice for Efficient Queries - Top 10 Practices)
PRB1581528
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.