Fixing WebSphere Large EAR Upload Errors | Generated by AI

Home 2025.10

Understanding the Issue

The “multipart file upload error” (often something like org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. File too large (errno:27)) typically occurs when updating an EAR file in IBM WebSphere Application Server (WAS) via the Administrative Console. This is common for larger EAR files (e.g., >20MB) due to limits on file uploads, temporary storage, heap memory, or OS resource constraints. It’s not an issue with the EAR itself but with how the console handles the HTTP multipart upload.

Quick Fixes to Try First

  1. Copy the EAR to the Server and Deploy Locally:
    • Use FTP/SCP to transfer the new EAR file to a directory on the WAS server (e.g., /opt/IBM/WebSphere/AppServer/installableApps/).
    • In the Admin Console: Go to Applications > Application Types > WebSphere enterprise applications.
    • Select your existing application > Update.
    • Choose Replace or add a single module or Replace the entire application, then select Local file system and point to the copied EAR path.
    • This bypasses the multipart upload over HTTP.
  2. Increase OS File Size Limits (UNIX/Linux Servers):
    • The error errno:27 often means the file exceeds the ulimit for the process.
    • Run ulimit -f as the WAS user (e.g., webadmin) to check the current limit.
    • Set it to unlimited: Add ulimit -f unlimited to the user’s shell profile (e.g., ~/.bash_profile) or the server’s startup script.
    • Restart the Deployment Manager (dmgr) and retry the upload.

Configuration Changes in WAS

  1. Increase Heap Size for Deployment Manager:
    • Large EARs can cause OutOfMemory during processing.
    • In Admin Console: Servers > Server Types > Administrative servers > Deployment Manager.
    • Under Java and Process Management > Process definition > Java Virtual Machine:
      • Set Initial heap size to 1024 (or higher, e.g., 2048 for very large EARs).
      • Set Maximum heap size to 2048 (or higher).
    • Save, restart the dmgr, and retry.
  2. Adjust HTTP Session or Post Size Limits (If Applicable):
    • For web container limits: Servers > Server Types > WebSphere application servers > [Your Server] > Web Container > HTTP transports.
    • Increase Maximum post size (in bytes) if it’s set low.
    • Note: This affects the admin console’s web app indirectly.

For large or frequent updates, avoid the console entirely—it’s unreliable for big files. Use the wsadmin scripting tool (Jython or JACL) to update the application.

Steps:

  1. Copy the new EAR to a server-accessible path (e.g., /tmp/myapp.ear).
  2. Launch wsadmin: 
    /opt/IBM/WebSphere/AppServer/bin/wsadmin.sh -lang jython -user admin -password pass
  3. Run this Jython script to update: 
    AdminApp.update('MyAppName', 'app', [-Map ModulesToApps, '[-MapWebModToVH [[default_host MyContext virtual_host]] ]'], [-Operation update], [-appname MyAppName], [-MapModulesToServers [[MyModule MyServer]]], [-nodefaultoptions], [-preCompileJSPs false], [-contextroot MyContext], [-noTxImport], [-connType SERVER], [ -contenturi /tmp/myapp.ear ])
AdminConfig.save()
    • Replace MyAppName with your app’s name, MyContext with the context root, MyServer with the target server/cluster, and /tmp/myapp.ear with the EAR path.
  4. Sync nodes if in a clustered environment: AdminControl.invoke(AdminControl.completeServers(), 'sync').
  5. Restart the app: Applications > [App] > Restart.

This method is faster, avoids upload limits, and is scriptable for automation (e.g., via Jenkins).

Additional Tips

If none of these resolve it, share the exact error message and WAS version for more tailored advice.

References

Back

x-ai/grok-4-fast

Donate