ignore-stuck-threads

 
in weblogic 10.3 (if not patched yet), default behavior of a work manager when one of the threads ‘belonging’ to it gets STUCK is shutting itself down.
 
The simplest thing to do to avoid this behavior is to enable the ‘Ignore Stuck Threads’ property of the work manager. This property can be configured using weblogic administration console.
 
however, this solution may cause other problems. if the work manager at hand does not have a ‘Maximum Threads Constraint’ or has one with a big ‘Count’, your server may face some resource problems: the work manager can consume a pretty good amount of the threads (assuming your threads over that work manager tending to get STUCK at the time). to avoid this problem, the initial solution can be extended, configuring the work manager in detail.
 
shutdown of a work manager can be delayed to a pre-determined amount of STUCK threads; you can tell the work manager how many STUCK threads should it have to shut itself down. but, unfortunately, this configuration cannot be done using weblogic administration console. instead, you should edit ‘config.xml’ file of your domain to configure the work managers in that way:

<work-manager>
    <name>${wm_name}</name>
    ...
   <work-manager-shutdown-trigger>
        ...
        <stuck-thread-count>${n}</stuck-thread-count>
        ...
    </work-manager-shutdown-trigger>
    ...
</work-manager>

you may further configure a work manager to have its own ‘Stuck Thread Max Time’, independent of the server. simply, add a max-stuck-thread-time in work-manager-shutdown-trigger:

<work-manager>
    <name>${wm_name}</name>
    ...
    <work-manager-shutdown-trigger>
        ... <!-- not sure if more elements available -->
        <stuck-thread-count>${n}</stuck-thread-count>
        <max-stuck-thread-time>${t_in_seconds}</max-stuck-thread-time>
        ... <!-- not sure if more elements available -->
    </work-manager-shutdown-trigger>
    ...
</work-manager>