Hi sudhir,

May I know the version of your application and screenshot of mendix environment activity ?

Also need to know whether the appliaction requested for shutdown after this error.

if it is possible can the share the error log file?

Recommended Initial Analysis

Before making any changes to the Mendix connection-pool configuration, I would first recommend analyzing the application behavior and identifying what is consuming the database connections.

The borrowMaxWaitDuration=PT10S message indicates that a request was waiting for an available database connection and timed out after 10 seconds. Increasing this timeout may only delay the failure; it does not address the underlying reason why connections are not being released quickly enough.

I would recommend focusing on the following areas first:

1. Analyze long-running microflows and queries
2. Identify microflows that are taking a significant amount of time to execute, particularly microflows running through Task Queues or background processing.
3. Check whether any queued microflows are processing a large number of records or executing database-intensive operations.
4. Analyze Task Queue activity
5. Check whether multiple queue items are being processed concurrently during the morning hours.
6. Pay particular attention to:
   • Large batch processing
   • Scheduled events
   • Integration processing
   • Data synchronization
   • Import/export processes
   • Reports or document generation
   • Microflows iterating over large datasets
7. Analyze the login process
8. Since the issue appears to occur when users start accessing the application in the morning, check what happens when a user logs in.
9. Review the microflows and data sources triggered during login and initialization. In particular, check whether any page or microflow is retrieving a very large dataset immediately after login.
10. For example, avoid scenarios where a page or microflow retrieves thousands or millions of records when only a small subset is actually required.
11. Review page data sources
12. Check the data sources used on the initial/home pages and frequently accessed pages.
13. Look for:
    • XPath retrieves returning a large number of objects
    • Unnecessary database retrieves
    • Retrieves inside loops
    • Multiple nested data sources
    • Complex XPath constraints
    • Sorting/filtering on non-indexed attributes
    • Loading large datasets into memory unnecessarily
14. Check database-intensive microflows
15. Look for microflows that perform operations such as:

Retrieve large dataset
       ↓
Loop through records
       ↓
Retrieve related data
       ↓
Perform calculations/updates
       ↓
Commit records

1. If these operations are processing a large volume of data, they can keep database connections occupied for an extended period.
2. Correlate the issue with the morning workload
3. Since the issue occurs primarily during morning hours, check whether there is a scheduled event, Task Queue workload, integration, report generation, or batch process running around the same time.
4. It would be useful to compare:
5. Scheduled/background processing time
   
6. versus
   
7. Time when users start logging in
8. If a heavy background process is already consuming database connections when users begin accessing the application, this could explain the connection-pool exhaustion.
   
   

Recommendation

Therefore, I would not recommend increasing the connection-pool wait time or pool size as the first step.

First identify:

Which microflows/queries are consuming the connections?

Then determine:

Why are they taking so long to complete?

After identifying the root cause, optimize the relevant microflows, queries, retrieves, indexes, Task Queue configuration, or background processing.

Only after this analysis should we consider whether ConnectionPoolingMaxWait or the connection-pool size needs to be adjusted.

This approach will help ensure that we are fixing the underlying performance issue rather than simply allowing requests to wait longer for an already-exhausted connection pool.