We’re running Windchill 11.1 M030 in a clustered environment (4 nodes) and experiencing severe UI freezes in the tooling management module during peak usage hours (10am-2pm). The UI becomes completely unresponsive for 30-60 seconds, impacting around 80 concurrent users.
Our monitoring shows connection pool exhaustion right before freezes occur:
WARNING: Pool exhausted - waiting threads: 47
active connections: 50/50
wt.pom.dbcp.maxActive=50
The JDBC pool sizing seems inadequate for our clustered deployment with peak loads. We’ve tried increasing maxActive to 75 per node, but that just delayed the problem. Query optimization might also be needed as some tooling queries take 8-12 seconds during these periods.
Has anyone successfully tuned connection pools for clustered Windchill deployments with heavy tooling module usage?
We had this exact issue on our 11.1 M030 clustered deployment last year. Here’s the comprehensive solution that addressed all three focus areas:
JDBC Pool Sizing for Clustered Deployment:
Your current 50 connections per node is insufficient. For 80 concurrent users across 4 nodes with tooling module, configure:
This gives you 400 total connections (100 per node) with proper idle management. The key is the minIdle setting - it keeps connections ready for burst traffic.
Clustered Deployment Considerations:
Enable connection validation to prevent stale connections in your cluster:
Also configure your load balancer for least-connections algorithm instead of round-robin to prevent the imbalance issue mentioned earlier.
Query Optimization:
Those 8-12 second tooling queries need indexes. Add these to your database:
CREATE INDEX idx_tool_status ON tool_master(status, last_modified);
CREATE INDEX idx_tool_assign ON tool_assignment(tool_id, assignment_date);
After implementing all three areas, our query times dropped to 1-2 seconds, pool exhaustion disappeared, and UI freezes were completely eliminated. The combination of proper pool sizing for clustered architecture, connection validation, and query optimization solved the problem permanently.
Monitor your connection pool metrics for a week after changes to fine-tune maxActive if needed.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this pattern before in clustered environments. Your pool size of 50 per node is actually too small for 80 concurrent users across 4 nodes. The math doesn’t work out - you need headroom for connection spikes.
But before just increasing pool size, check if you have connection leaks. Run this query during peak hours to see actual connection usage patterns and identify any queries holding connections too long. That 8-12 second query duration is a red flag.
Good point about connection leaks. I ran connection monitoring and found several tooling queries that weren’t closing connections properly in our custom workflow. The long-running queries were indeed holding connections open. We’re reviewing our custom code now to fix those leaks before adjusting pool sizing further.
Connection leaks are definitely part of the issue, but you also need proper pool configuration for clustered deployments. The ratio should account for node failover scenarios too. I typically recommend 20-25 connections per node per 20 concurrent users as a baseline, then tune based on actual query patterns and response times.
For tooling management specifically, check if you have indexes on the tool_master and tool_assignment tables. Missing indexes on frequently queried columns can cause those 8-12 second query times, which then holds connections longer than necessary. Run EXPLAIN PLAN on your slowest tooling queries to identify missing indexes. That alone might cut your connection hold time in half.
Also verify your load balancer settings aren’t creating connection imbalances across nodes. I’ve seen cases where sticky sessions combined with poor pool distribution caused some nodes to exhaust pools while others sat idle. Check connection distribution across all 4 nodes during peak hours to ensure even load distribution.
Tested this on Windchill 11.1 M030 with four clustered nodes, and bumping wt.pom.dbcp.maxActive to 100 eliminated the tooling UI freezes during our peak morning load.