On 18/10/2010 01:22, Benoit Perroud wrote: > 2010/10/17 Phil Steitz <phil.ste...@gmail.com> > >> On 10/17/10 8:53 AM, Benoit Perroud wrote: >> >>> Making pool be able to be resized at runtime will introduce extra >>> complexity, that could be otherwise totally delegated to a BlockingQueue >>> as >>> backend structure. >>> >> >> I don't understand exactly what you are saying here. The question is >> should the user-exposed properties governing the size, max number of idle >> elements, etc. be mutable at runtime. Regardless of the choice of data >> structure to maintain the pool, deciding this in the negative puts some >> serious constraints on user code. >> >> > I mean, if we decide to use a BlockingQueue as backend and allow users to > resize the queue, then we will need to reinstanciate the queue at every size > change. > > In jdbc-pool at least, in case of unfair queue, they use a > ArrayBlockingQueue, and thus the queue size is not resizable on the fly. > > >> We should talk about why the Tomcat devs decided to implement their own >> FairBlockingQueue.
ENOCLUE. There might be something in the Javadoc but most likely not. > Good point for the fair queue. Is something from Tomcat reading this ML ? Some*one* is, yes. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
