views:

837

answers:

1

By default WebLogic kills stuck threads after 15 min (600 s), this is controlled by StuckThreadMaxTime parameter. However, I cannot find more details on how exactly "stuckness" is defined. Specifically:

  • What is the point at which 15 min countdown begins. Request processing start? Last wait()-like method? Something else?
  • Does this apply only to request-processing threads or to all threads? I.e. can a request-processing thread "escape" this protection by spawning a worker thread for a long task? Especially, can it delegate response writing to such a worker without 15 min countdown?

My usecase is download of huge files through a permission system. Since a user needs to be authenticated and have permissions to view a file, I cannot (or at least don't know how) leave this to a simple HTTP server, e.g. Apache. And because files can be huge, download could (at least in theory) take more than 15 minutes.

+3  A: 

Weblogic does NOT kill stuck threads after the StuckThreadMaxTime. It cannot do so, the message is only a status info so that you (i.e. admin) is aware that the thread has crossed 10 mins (600 sec = 10 min, not 15)

This is a configurable value.

The timer starts when the thread begins processing the request within the server. The thread will not be killed but will actually go on processing until the operation is over. so in your case, you do not need to worry about the thread getting killed, it has just informed you about the time taken - which you are aware of in this use case.

It applies to all threads AFAIK - any spawned thread will also operate under the same rules.

IMHO, Weblogic (or any app server) is not the place to store and serve large files. This is ideally meant for the Web server tier - we use SunOne on which the file download servlet can be run. In your case, you would need Tomcat along with your Apache for optimizing this.

JoseK
OK, but as I know it can redeploy the whole application if there are too many stuck threads, no? I might have mixed things up with session timeout — we had some problems with that in the past. About files — the application is so large and buggy that there's no time to spend on optimizing as there are always more pressing issues.
doublep
The server will stop responding to new requests if there are too many stuck threads - but in your case they are not really 'stuck' but are processing long requests. A better approach is to give the FileDownloadServlet it's own execute thread pool - on WL10 this will be a dedicated WorkManager. This ensures that any threads stuck/affected in the download will not affect the rest of the server processing normal requests. see here for more - http://download.oracle.com/docs/cd/E11035_01/wls100/config_wls/self_tuned.html#wp1059038. You can define a dispatch policy for that servlet.
JoseK
Thank you for the answer and clarifications.
doublep