WebLogic stuck thread protection

Question

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.

Flycatcher

Answer 1

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.

Motor

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. – Flycatcher

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 - download.oracle.com/docs/cd/E11035_01/wls100/config_wls/…. You can define a dispatch policy for that servlet. – Motor

Is there a way of killing off the stuck threads in weblogic, once i admin have figured this out? – Common

@f1wade: no - it's not possible – Motor

great thanks for confirming, is there a way to mark the thread as not to be used, or to clear its queue? – Common

Read why WebLogic has no runaway thread protection blog.pasker.net/2008/04/17/… – Prattle

Answer 2

The WLS10 WorkManager documentation can cause some real headscratching. See http://blogs.oracle.com/jamesbayer/2010/01/work_manager_leash_for_slow_js.html for a step by step example of how to define a WorkManager for a webapp in weblogic.xml and assign a specific servlet to use it.

Adding to that example, you can add <ignore-stuck-threads>true</ignore-stuck-threads> to the <work-manager> definition which should prevent threads working for that WorkManager from being counted against a failed server state.

Assail

The blog post has moved to blogs.oracle.com/jamesbayer/… – Expiry