Resiliency with the WebSphere WorkManager APIs

WebSphere Application Server provides the com.ibm.websphere.asynchbeans  and commonJ APIs (CommonJ work manager contains a subset of the asynchronous beans work manager methods)  that provide for the full support of application controlled threading, asynchronous callbacks and scoped alarms and subsystem monitors.  If you prefer standard APIs then you can use commonJ APIs instead of websphere.asynchbeans. I want to highlight a couple of settings that should be tuned when configuring both types of WorkManagers (Thread pools that administrators create for Java EE applications).

WorkManager Admin Console Panel

WebSphere Application Server provides the ability to set an absolute timeout on the Work items submitted to WorkManager via the administrative web console. The Work timeout specifies the number of milliseconds to wait before a scheduled work object is released. If not specified or set to 0, the timeout is disabled. Customers should set this Work Timeout to some finite (non-zero) value so that the stuck threads get a chance to release their respective Work items. The implementor of the Work (Applications implement work objects to run code blocks asynchronously) then should take corrective action in asynchbeans.Work.release() or commonj.work.Work.release() such as exiting out of the synchronous read operations or calling Thread.currentThread().interrupt(). This works for both WorkManager and commonj APIs.  Doing this will allow your application threads to react to non responsive endpoints like remote web services or other calls where the code is waiting indefinitely synchronously on another resource.  *credit to Nathan Rauh for helping clarify this cool feature