Work manager configuration

Question

All,
I'm prototyping work manager configuration for our app under WLS 9.2.
I think I want 2 work managers: one for async batch-type operations and one for sync operations. The async work involves making parallel calls and not necessarily waiting for a response. The sync work involve parallel calls and waiting for a response (such as a web service request resulting in 2 parallel backend calls.) Mainly I don't want to allow the async operations to hog the resources and cause slow responses or timeouts for the users. At the same time, however, I don't want to articifically handicap the async processing during periods of low sync load. If I create 2 fairshare work managers with a 50% share each, during the night when users are not submitting sync requests, will the async batch work manager be allowed to scale up?
A long time ago I wrote a parallel processing facade that used a single JMS queue to achieve paralelism. I quickly learned the hard way that if you have parallel calls that call back into the framework (that is, thread A spawns thread B and C and waits for replies and thread B spawns thread D and E and waits for replies,) then you can wind up blocked forever because A can't complete without B, but B can't complete without D, but D can't run because A and B are hogging all the threads. Is this a risk with the WLS work manager? It seems that as long as I don't cap the thread count, then it might be sufficient to have just 1 big pool. My concern is what will happen when WLS decides not to spawn any more threads and instead just queues up incoming work?
thanks

Answer 1

First Part:
If you are setting the fairshare to 50 % then the server will split the requests equally between the sync and async apps during a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads.In this case the thread pool is equally utilized by each app.
Now, during the night time the sync WM is not working and this will free the thread pool for the async WM alone. The async work manager will utilize the whole thread pool and hence will scale up.
Second part:
Correct me if I'm wrong, I don't think there is a point where WLS will decide not to spawn a new thread. Spawning threads is a continuous process until the server goes down. The self-tuning thread pool would also adjust its pool size automatically based on the throughput history that WLS gathers.
You will have to kill the stuck threads to free up the pool or setup a max thread constraint and allow only a limited number threads to execute requests. I think you would also need to setup a capacity constraint to reject all the requests that are queued up for work.