Requirement
I had about 5 OSB proxy services which I wanted to set similar dispatch policy. I wanted to set max thread constraints on all the proxy services as 3 so that each proxy cannot have more than 3 concurrent threads.
Original Implementation
I had created a work manger by name WorkManagerMaxThree which uses a Max Thread Constraint called MaxThreadThree. MaxThreadThree is configured to have a count of '3'. This work manger was used as dispatch policy for all the 5 proxy services. The idea being that each proxy can have a max of 3 threads at any point of time.
Problem
All the 5 OSB proxy services were subscribing to different JMS queues. When using the same work manger I observed that some of my proxy services stopped working and would not process any message even if there were messages waiting to be picked up in the queue.
Issue
After through analysis (Oracle Support was of no help), I found out that when using the same work manger, all the 5 proxy services will share the same thread pool. So in this case I had 5 proxy services sharing a pool of 3 threads. This means that at any given point of time I had only 2 or 3 proxy service running and the others sitting idle and waiting for a thread.
Resolution
Once the issue was identified, I created individual Work Managers and individual Max Thread Constraints for each of the proxy service. This resolved the problem and I never saw the proxy services going idle again.
I had about 5 OSB proxy services which I wanted to set similar dispatch policy. I wanted to set max thread constraints on all the proxy services as 3 so that each proxy cannot have more than 3 concurrent threads.
Original Implementation
I had created a work manger by name WorkManagerMaxThree which uses a Max Thread Constraint called MaxThreadThree. MaxThreadThree is configured to have a count of '3'. This work manger was used as dispatch policy for all the 5 proxy services. The idea being that each proxy can have a max of 3 threads at any point of time.
Problem
All the 5 OSB proxy services were subscribing to different JMS queues. When using the same work manger I observed that some of my proxy services stopped working and would not process any message even if there were messages waiting to be picked up in the queue.
Issue
After through analysis (Oracle Support was of no help), I found out that when using the same work manger, all the 5 proxy services will share the same thread pool. So in this case I had 5 proxy services sharing a pool of 3 threads. This means that at any given point of time I had only 2 or 3 proxy service running and the others sitting idle and waiting for a thread.
Resolution
Once the issue was identified, I created individual Work Managers and individual Max Thread Constraints for each of the proxy service. This resolved the problem and I never saw the proxy services going idle again.
