On 5/6/11 9:29 AM, Simone Tripodi wrote: > Hi Phil, > thanks for taking in consideration my thought! I wouldn't maintain 3 > version either, anyway we could "evolve" the actual Pool2 > implementation into the one described in the roadmap - that I > perfectly agree and like, no objections there! - little step by little > step, releasing early and often intermediate versions.
Again, i appreciate the sentiment here and would under normal circumstances support it; but in this case you do in fact end up having to support three different versions if you go down this path and actually release a pool 2 based on the 1.x code (with 1.5 required JDK) and then pool 3 with rewritten internals and refactored API (and 1.6+ JDK). Once you have released the 2.0 version based on the 1.x internals and API, you are signing up to support both of them. That is what I want to avoid. As I said in another post, "release early, release often" is challenged in this case for two reasons: 1) major, incompatible releases of widely reused library components cannot be "often" - so the "often" part needs to be punctuated by runups to major releases 2) pool sits at the core of many server applications and at a low level in the dependency hierarchy, so "early" badly bugged releases can wreak havoc once they get into the food chain. Item 2) above can be handled by aggressive patching / release classification, etc.; but it underscores the point that whatever we release in [pool] we need to be prepared to support with patch releases. So the 1.x, 2.x, 3.x story is unavoidable unless we merge 2.x with 3.x (or logically, merge 2.x into 1.x; but I don't see a way to do that without breaking compatibility). > In that way, users with OSs that don't support JVM6 yet, still have > the opportunity to update pool library without having the need of > upgrading the whole platform. I understand, but just don't see a practical way to do it. As we dig into the 2.0 code, it could be Mark's initial analysis is revised and we find a way to make things work for both. > By the way, even if looks like I'm a part of minority, I'll respect > the decision you'll made and won't oppose any veto, and continue > contributing. Thanks! Phil > Have a nice day, all the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, May 6, 2011 at 6:15 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> 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 >> >> > --------------------------------------------------------------------- > 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
