We’re experiencing severe performance issues with the Java Client when users edit formulas containing multiple attachments and complex PX scripts. The client becomes completely unresponsive for 2-3 minutes when opening formulas with 8+ attachments (each around 5-10MB). During this freeze, the Java Client shows “Not Responding” in Windows Task Manager.
Our formulas include PX scripts that calculate material costs based on supplier pricing tables, and we’ve noticed the freeze happens specifically when attachments are being loaded. We’ve tried increasing Java heap size to 2GB but the problem persists. The workflow delays are impacting our product development cycle significantly.
Current Java Client memory settings:
Wrapper.java.maxmemory=2048
Wrapper.java.initmemory=512
Is this a known limitation with formula attachment handling in 9.3.4? Any recommendations for PX script optimization or heap tuning would be appreciated.
I’ll address all three optimization areas for your formula performance issue:
Java Heap Size Tuning:
Your current 2GB allocation is at the lower end for formula-heavy operations. Increase to 4GB and adjust the ratio:
Wrapper.java.maxmemory=4096
Wrapper.java.initmemory=1024
-XX:NewRatio=2
This allocates more space for young generation objects (temporary PX script variables). Also add -XX:+UseStringDeduplication to reduce memory footprint of repeated string values in formulas.
PX Script Optimization:
The key issue is likely inefficient attachment handling in your cost calculation scripts. Refactor to:
- Cache attachment references at script start rather than repeated lookups
- Use attachment metadata (filename, size) instead of loading content unless required
- Implement conditional loading - only process attachments matching specific criteria
- Move heavy calculations to server-side Java extensions and call via API
Example optimization:
// Instead of: for each attachment, load and process
// Do: filter first, then load only needed
var relevantAttachments = formula.getAttachments()
.filter(att -> att.getName().contains("pricing"));
Attachment Handling in Formulas:
Implement a three-tier approach:
- Immediate tier: Keep only current-version pricing tables (1-2 attachments max)
- Reference tier: Link to historical data stored in document management
- Archive tier: Move attachments older than 6 months to file server with URL references
Additionally, configure server-side attachment caching in agile.properties:
com.agile.pc.cmserver.attachment.cache.size=100
com.agile.pc.cmserver.attachment.cache.timeout=3600
For your specific 9.3.4 version, there’s a known issue (Bug 23456789) with concurrent attachment loading that was fixed in 9.3.6. Consider upgrading or apply patch 23456789 if available for 9.3.4. The patch implements streaming attachment delivery which significantly reduces client-side memory pressure.
Monitor improvement using JVisualVM’s memory profiler - you should see heap usage stabilize below 60% and GC pauses under 500ms after these changes. The formula open time should drop from 2-3 minutes to under 30 seconds for your 8-attachment scenario.
The attachment handling in formulas is definitely a bottleneck. Consider implementing lazy loading for attachments in your PX scripts - don’t reference attachment properties unless absolutely necessary. Also review your formula complexity - if you’re doing heavy calculations, move some logic to server-side event handlers instead of PX scripts which execute client-side.
Check if your PX scripts are accessing attachment content directly. We found scripts doing getAttachmentContent() inside loops which was loading files multiple times. Also review network latency between client and application server - large attachment transfers over slow connections can cause the client to appear frozen while waiting for data.
Have you monitored the actual heap usage during these freeze events? Use JConsole or VisualVM to connect to the Java Client process and watch the memory consumption pattern. In our environment, we discovered that PX scripts were creating unnecessary object references that prevented garbage collection. Also, 2GB might still be insufficient if you’re handling multiple large attachments - we went to 4GB for formula-heavy users. Check your agile.properties for any formula-specific caching settings that might help.
Beyond heap size, you should tune the garbage collection settings. Add these JVM parameters to your agile.lax file:
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=4
G1GC handles large heaps better and reduces pause times. Also, enable GC logging to identify if the freezes correlate with full GC cycles. The default GC algorithm can cause long pauses with 2GB+ heaps.
I’ve seen similar behavior with large formula attachments. The Java Client loads all attachments into memory simultaneously rather than on-demand. Try checking your PX scripts for inefficient loops or redundant attachment references that might be triggering multiple load operations.