Gabe, On Snow I raised the minPoolSize to the number of jobs I am able to run concurrently on our servers via Resource Manager.
I am running minPoolSize=40 AND maxPoolSize=40 and everything works fine. I have noticed that if I flood the Workflow manager too quickly the jobs tend to wait until all 40 jobs are ready before all of them will move from STAGING to PGE_EXEC. Hope that helps. -Cam On Mon, Mar 18, 2013 at 10:37 AM, Mattmann, Chris A (388J) < [email protected]> wrote: > Hi Gabe, > > The best docs I can point you at are here: > > http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-s > ummary.html#package_description > > > > I would recommend also reading: > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Pooled > Executor.html > > > That really explains what the purpose of those diff properties are. > > Cheers, > Chris > > > On 3/14/13 1:57 PM, "Resneck, Gabriel M (388J)" > <[email protected]> wrote: > > >Hi, guys! > >I've run into a problem with the Workflow Manager in release 0.3. The > >number of active threads allowed by the pool seems to be dictated by the > >minimum thread count when the queue supplied to the pool object is > >unlimited. The default number (6) is a bit low for our purposes, so I > >was wondering how you guys have dealt with this issue in the past. Did > >you simply increase the minimum pool size or implement another solution? > >If you increased the minimum pool size, what was the highest that you > >have used and did you see any issues as a result? > >Thanks! > > > >Gabe =) > > > > -- Sent from a Tin Can attached to a String
