Bulk import of simulation data via REST API fails due to file size limit

PLM Windchill
, , , , , , , ,
1

We’re uploading large simulation result files (CFD analysis outputs, typically 250-400MB) through Windchill 12.0 REST API to link them with design iterations. The upload fails consistently with ‘file size exceeded’ errors around 100MB mark.

Our simulation workflow generates these large result files that need to be associated with WTPart objects for traceability. Standard file attachments work fine, but bulk simulation data imports fail:


POST /Windchill/servlet/odata/ProdMgmt/Documents
Content-Type: multipart/form-data
Error: Request entity too large (100MB limit)

Is there a configuration to increase REST API file upload limits? We’ve checked wt.content.maxFileSize property but unsure if that applies to API uploads or just UI operations.

system 2

The issue requires addressing all three configuration layers - REST API file upload limits, wt.content.maxFileSize property, and Tomcat server configuration. Here’s the comprehensive solution:

1. REST API File Upload Limits: The REST API respects multiple configuration boundaries. First, update wt.properties:


wt.content.maxFileSize=524288000
# 500MB in bytes

This controls Windchill’s content service upload limit. However, this alone won’t solve the problem.

2. Tomcat Server Configuration: Edit WT_HOME/tomcat/conf/server.xml and modify the HTTP Connector:

<Connector port="8080"
  maxPostSize="524288000"
  maxSwallowSize="524288000"/>

Both attributes must be set. maxPostSize limits POST request size, maxSwallowSize prevents Tomcat from rejecting large payloads. Without these, Tomcat rejects uploads before Windchill processes them.

3. Additional Infrastructure Considerations:

Reverse Proxy (if applicable): If using Apache, add to httpd.conf:


LimitRequestBody 524288000

For nginx:


client_max_body_size 500M;

Performance Optimization: For 400MB files, implement these best practices:

  • Use chunked transfer encoding in your API client
  • Set appropriate timeout values (connection timeout: 300s, read timeout: 600s)
  • Upload during off-peak hours for initial bulk imports
  • Consider background processing: POST to create document object first, then upload content separately
  • Monitor method server memory - large uploads consume heap space during processing

Restart Sequence:

  1. Stop Windchill method server
  2. Update wt.properties and server.xml
  3. Clear Tomcat work directory cache
  4. Start method server
  5. Verify with test upload

Validation: Test incrementally: 150MB, 250MB, then 400MB files. Monitor WT_HOME/logs/MethodServer-*.log for any remaining constraints. If uploads still fail, check database storage configuration - some databases have BLOB size limits that may need adjustment.

For production deployment, document these settings in your change control system as they’ll need reapplication after Windchill upgrades.

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.

3

The wt.content.maxFileSize property does apply to API uploads. Check your current setting in site.xconf or wt.properties. Default is often 100MB. You’ll need to increase it and restart the method server for changes to take effect.

4

We increased wt.content.maxFileSize to 500MB and restarted, but still hitting the same 100MB limit. Could there be another configuration layer blocking larger uploads?

5

Tomcat has its own upload size limits independent of Windchill properties. Check your server.xml configuration for maxPostSize and maxSwallowSize attributes on the Connector element. These default to relatively small values and need to be increased for large file uploads.

7

Also check if you have a reverse proxy or load balancer in front of Windchill. Apache, nginx, or F5 configs often have their own upload limits that override application settings. We had similar issues that turned out to be nginx client_max_body_size set to 100MB.

9

Good catch on the proxy - we do have Apache in front. But even after adjusting that, should we be concerned about performance? Uploading 400MB files through REST API seems like it could impact server responsiveness.

10

For very large files, consider chunked uploads instead of single POST requests. The REST API supports multipart uploads where you can break the file into smaller segments. This improves reliability and allows resume capability if network issues occur during upload.