Let me provide a comprehensive solution addressing all the factors contributing to your heap space errors.
JVM Memory Tuning:
For EBOM structures of your size, configure these JVM parameters in your method server startup script:
-Xms4096m -Xmx8192m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
Start with 8GB heap maximum. The G1 garbage collector handles large heaps more efficiently than the default collector. Monitor the GC logs to see actual memory usage patterns - you may need to adjust further for your specific data.
Recursive EBOM Structure Optimization:
The key issue is how BOM Compare handles shared sub-assembly references. By default, it loads each occurrence separately into memory. Modify your export approach:
- Enable structure sharing detection in preference settings (if available in 12.3)
- Pre-process your BOM to identify highly-referenced sub-assemblies (referenced >10 times)
- For these common sub-assemblies, export them separately first, then reference them in the main export
You can identify recursive patterns with this query approach:
// Query to find highly-referenced components
SELECT child_id, COUNT(*) as ref_count
FROM PSEBOMViewRevision
WHERE parent_structure_id = 'your_top_assembly'
GROUP BY child_id
HAVING COUNT(*) > 10
Batch Export Configuration:
The batch export in TC 12.3 doesn’t help with single large structures, but you can implement a pseudo-batch approach:
- Configure BOM Compare to export by assembly level rather than full traversal
- Set max_traversal_depth in your site preferences to limit recursive depth per export operation
- Export levels 1-3, then 4-6, then merge results
BMIDE Property Configuration:
Review your custom BOM line properties. Check these specific areas:
-
Computed Properties: Disable or cache any properties that perform calculations during load. Set them to load-on-demand rather than load-with-object.
-
Property Definitions: In BMIDE, verify that your custom properties have appropriate loading policies:
<property name="custom_cost">
<loading-policy>ON_DEMAND</loading-policy>
<caching-policy>CACHE_ENABLED</caching-policy>
</property>
- Effectivity Properties: If you’re using custom effectivity, ensure they’re not triggering recursive database queries for each BOM line.
Database Connection Pool:
Adjust these properties in wt.properties:
wt.pom.dbcp.maxActive=100
wt.pom.dbcp.maxIdle=50
wt.pom.dbcp.maxWait=180000
Larger pools prevent connection waits that cause memory buildup.
Monitoring and Validation:
After implementing these changes:
- Enable verbose logging for BOM Compare operations
- Monitor heap usage during export with JConsole or VisualVM
- Track export completion times and memory peaks
- Test with progressively larger structures (5K, 8K, 10K, 12K components)
Alternative Approach:
If memory issues persist even after tuning, consider using the Teamcenter SOA API to build a custom export utility that streams data rather than loading everything into memory. This gives you full control over memory management and allows processing structures of any size.
The combination of proper JVM tuning, recursive structure optimization, and BMIDE property configuration should resolve your heap space errors for structures up to 15K components. For anything larger, the custom streaming export approach becomes necessary.