BOM synchronization times out when processing large assemblies in MCO management

PLM Windchill
, , , , , , , ,
1

Our BOM synchronization operations are consistently timing out when processing assemblies with more than 800 components. The sync process runs for approximately 45 minutes before throwing a timeout exception, leaving the BOM in an inconsistent state.

We’ve looked at timeout configuration parameters in site.xconf but increasing them doesn’t solve the underlying performance issue. The database query performance seems problematic - we can see long-running queries in the DB logs during sync operations. Our assembly decomposition strategy might also need optimization since we’re processing the entire structure in a single transaction.

The error log shows:


BOMSyncTimeout: Operation exceeded 2700000ms limit
at com.ptc.mco.sync.BOMProcessor.syncStructure
Transaction rollback - partial BOM data committed

This is delaying manufacturing releases significantly. Any recommendations for batch processing optimization or timeout tuning?

2

We confirmed that full structure validation is enabled and visualization is being generated during sync. We’ve also noticed that our PartStructure table has over 2 million rows with no recent index maintenance.

3

Check if you’re synchronizing visualization data along with BOM structure. If PVZ generation is enabled during sync, that adds substantial processing time. Consider decoupling visualization processing from BOM sync - let the BOM sync complete first, then generate visualization representations in a separate background job.

4

Excellent diagnostics. You’ve identified multiple bottlenecks that need coordinated fixes. Here’s a comprehensive solution addressing all four focus areas:

1. Timeout Configuration Parameters (Immediate Relief): Update your site.xconf with these BOM-specific timeout settings:

<Property name="wt.mco.sync.timeout" value="7200000"/>
<Property name="wt.mco.batch.transaction.timeout" value="3600000"/>
<Property name="wt.mco.sync.maxRetries" value="3"/>

This extends timeouts to 2 hours for sync operations and 1 hour for batch transactions, with automatic retry logic. However, this is temporary - you need the optimizations below.

2. Batch Processing Optimization (Scalability Fix): Enable chunked processing in mco.properties:

com.ptc.mco.sync.batchSize=200
com.ptc.mco.sync.parallelThreads=4
com.ptc.mco.sync.commitInterval=50

This processes assemblies in 200-component batches across 4 parallel threads, committing every 50 components. Prevents monolithic transactions and enables incremental progress.

3. Database Query Performance Tuning (Root Cause Fix): Your 2M row PartStructure table needs immediate index optimization. Run these maintenance commands:

  • Rebuild indexes on PartStructure.parentId, PartStructure.childId, and BOMComponent.assemblyId
  • Update table statistics: EXEC sp_updatestats (SQL Server) or ANALYZE TABLE (Oracle)
  • Add composite index: CREATE INDEX idx_ps_parent_child ON PartStructure(parentId, childId, branchId)

This composite index dramatically improves recursive BOM traversal queries.

4. Assembly Decomposition Strategy (Architectural Improvement): Implement hierarchical sync processing:

  • Configure sync to process top-level subassemblies independently
  • Set maxDepth=3 for initial sync pass, then process deeper levels in subsequent passes
  • Enable delta sync mode: only process changed components rather than full structure
  • Disable visualization generation during sync: `wt.mco.sync.generatePVZ=false Run visualization as separate scheduled job during off-peak hours.

Implementation Sequence:

  1. Apply database index optimizations first (requires maintenance window)
  2. Update timeout and batch processing configurations
  3. Test with medium assembly (400-500 components) to validate improvements
  4. Implement hierarchical decomposition strategy for largest assemblies
  5. Monitor sync performance and adjust batch sizes based on actual throughput

Expected Results: With these changes, 800-component assemblies should sync in 8-12 minutes instead of 45+. The batch processing approach prevents timeout exceptions, while database tuning addresses the root performance issue. The decomposition strategy ensures scalability for even larger assemblies (2000+ components).

Monitor your MethodServer logs during the first few syncs to verify batch processing is working correctly and adjust thread counts based on your server capacity.