On 5/6/11 8:57 AM, Simone Tripodi wrote: > Honestly, I agree with Paul. Let's release early and often!
I understand the sentiment here, but I do not think it is practical or advisable. If you look deeply into the current [pool] code and the history of bugs that we have had to deal with, you will see that maintaining three versions of pool concurrently is a bad idea. We simply do not have the resources to do that. The 1.x code (which is still the guts of what is now in trunk) is complex and fragile. I am -1 for trying to support two versions of that code concurrently and I do not think it would be a responsible decision for this PMC to go down that path. Phil > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, May 6, 2011 at 5:54 PM, 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. >> >> 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 >> >> > --------------------------------------------------------------------- > 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
