"If you do nothing on dispatch policies in OSB proxy or business services, all is done in the Default Workmanager. But since some constructions, not only service call-outs, need other threads to finish the job, you can get stuck threads because the workmanager's threadpool gets empty having all or near to all threads waiting, leaving no threads to pickup work to free the others.
If all threads in the default queue become stuck, the server changes its health state to "critical.
If all threads in weblogic.admin.HTTP, weblogic.admin.RMI, or a user-defined execute queue become stuck, the server changes its health state to "warning.
Work Managers have a Ignore Stuck Thread options that gives the ability to execute long running jobs. "
Based on our need we can create one of following work manager's:
For OSB to work optimally and prevent floading WebLogic’s threadpool with hogged/stuck threads you should create 3 FairShareRequest classes in ratio of 33/33/33, to distinguish different “kinds of threadpools”.
- FTPPollingWorkManager: file based inbound OSB proxy services. Polling a filesystem (or FTP). Uses FairShareReqClass-1, and ignores stuck threads.
- InboudWorkManager: inbound OSB proxy services, not polling file based. Also uses FairShareReqClass-1, not ignoring stuck threads.
- CallOutWorkManager: Service Call Out operations in a OSB proxy. Uses FairShareReqClass-2.
- DeliveryWorkManager: outbound business services in OSB. Uses FairShareReqClass-3.
Comments
Post a Comment