0
votes

Configuration: We have iPlanet web server which sits before WebSphere portal 6.1 cluster (2) deployed in Linux machines.

When user tries to copy a 10 GB file across file systems (NFS mounted), we are using java run time to copy the file across to a different NFS mount, hoping that it would be faster than using any other java libraries.

proc = rt.exec("cp " + fileName + " " + outFileName);

Application deployed is a JSF portlet application.
a) session timeout is 60 mins on the app server and the application
b) we have an Ajax call from the client page to keep the session alive

User receives HTTP 500 within 3 minutes, while our logs show that file is still copying. Not sure why WebSphere is sending HTTP 500?

After 10 minutes are so file is copied, and when he clicks on refresh he can proceed.

Not sure what is causing this HTTP 500.

2

2 Answers

1
votes

WebContainer threads are not supposed to be used for long tasks. He's getting 500 after 3 minutes because that is the time WebSphere decides the thread is hung.

What you should be doing is using a WorkManager to perform that long task and the client can poll to check the status of the task.

If you consider upgrading to WAS v8/v8.5 in the near future a good idea will be to use Asynchronous Servlets for that

1
votes

The reason that your client receives an HTTP 500 error after a few minutes can happen for a few reasons. Without a stack trace and some relevant logging, it is impossible to know which component within WebSphere "woke up" after 3 minutes and stopped everything. It might be WebSphere's timeout setting for the Web Container thread pool, or it can be some other timeout - should be easily concluded from the logs.

To fix this, you can do one of the following:

  • Adjust the relevant timeout value (depending, again, on which timeout it is exactly).
  • Change your design so long-running tasks are executed in the background. You can use WebSphere's Work Manager API for that, or asynchronous beans / servlets.