On Fri, May 6, 2011 at 11:54 AM, Paul Benedict <pbened...@apache.org> wrote:
> Is it too radical to suggest POOL 2 be 1.5 and POOL 3 be 1.6? Just > bump up major version every time you target a new major JDK. > The argument that was made earlier is that it is a lot of work to do on 1.5 where 1.6 makes your life easier. There was another point made about DBCP going to 1.6. Gary > > On Fri, May 6, 2011 at 10:35 AM, Mark Thomas <ma...@apache.org> wrote: > > On 06/05/2011 16:24, Phil Steitz wrote: > >> On 5/6/11 3:43 AM, Mark Thomas wrote: > >>> Before I go too far down the road of the re-writing the core object > >>> allocation code for pool2, I'd like to get some clarity on what the > >>> minimum Java version targeted by pool2 should be. > >> > >> It is also logical to ask at this point if the rewrite is desirable > >> / necessary and what we expect to gain from it. I have pretty > >> consistently advocated this, but given the work and inevitable > >> stabilization required, we should at least ask the question. Seems > >> to me the goals should be 0) performance 1) maintainability 2) > >> robustness 3) (configurable?) fairness. Do you agree with these and > >> are you sure the rewrite is necessary to get them? > > > > Yes I agree. To address 0), we need to remove most/all of the > > synchronisation around object allocation. That means a re-write, almost > > certainly with java.u.c. I still have concerns around 1) & 2). The more > > I think about this problem, the more I realise I need to spend more time > > thinking about the problem. At the moment, I would rather take the time > > and get this right. > > > >>> It is currently 1.5. > >>> > >>> It would make the implementation of the FIFO/LIFO allocation option > >>> considerably easier if that was changed to 1.6. > >> > >> Can you explain a little what the problem is? > > > > Sure. In pool1 we have the ability (via CursorableLinkedList) to remove > > and insert idle objects at any point in the queue. We use this for the > > evictor and idle validation. It we switch to java.u.c (and I think it is > > almost certain we will have to to get the performance we want) there are > > far fewer options over object insertion/creation. > > > > In Java 1.5, LinkedBlockingQueue only supports FIFO. It is not possible > > to remove from the tail of the queue or insert at the head. That makes > > LIFO pretty much impossible to implement. > > > > In Java 1.6, LinkedBlockingDeque allows inserts and removals at either > > end of the queue. That solves the LIFO/FIFO issue but not the eviction / > > idle validation questions. I have some ideas about this but I am trying > > to avoid creating lots of complexity. I am also mulling over how to > > ensure that maxActive and friends are adhered to. > > > > Mark > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
