WorkManager and ignore-stuck-thread setting

Question

In WL 10.3, using an application scoped work manager with the following .war deployment descriptors:
web.xml:
<resource-ref>
<res-ref-name>wm/WorkManagerABC</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
weblogic.xml:
<work-manager>
<name>WorkManagerABC</name>
<fair-share-request-class>
<name>abcClass</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<ignore-stuck-threads>true</ignore-stuck-threads>
<min-threads-constraint>
<name>MinThreadsCountTen</name>
<count>10</count>
</min-threads-constraint>
<max-threads-constraint>
<name>MaxThreadsCountTwenty</name>
<count>20</count>
</max-threads-constraint>
</work-manager>
<wl-dispatch-policy>WorkManagerABC</wl-dispatch-policy>
( This particular app is meant to be a socket listener using javax.nio ). This results in WL seeing "stuck threads" after the default 600 seconds. In our clusters, our clusters are configured that 3 stuck threads cause a server restart by nm.
So I created the same objects at the domain level ( workmanager, min/max/fair-share ), with the workmanager set to ignore stuck threads.
web.xml
<resource-ref>
<res-ref-name>WorkManagerABC</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
weblogic.xml
<weblogic-version>10.3</weblogic-version>
<!-- no work manager defined -->
<wl-dispatch-policy>WorkManagerEni</wl-dispatch-policy>
The app deploys and simple web pages are processed within the WorkManagerABC wm. Although WL still marks 4 threads as hoggers, none of them are stuck. So no restart, and the server Health stays OK.
So a workManager at the server level obeys the "Ignore Stuck Threads" while an application scoped workmanager does not.

Answer 1

I wasn't too disappointed that the application-scoped workmanager didn't obey the stuck threads; I'd rather have the work manager configurable at the server console level without having to involve customized deployment plans to override hard-coded thread restraint levels in the app's deployment descriptors.
I think having it defined within the server console will make it simpler to manage the different performances in production versus qa, etc., than having it defined within the app and then adjusting it in each environment.