commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [POOL2] Java 1.5 or 1.6?
Date Fri, 06 May 2011 16:49:37 GMT
On Fri, May 6, 2011 at 11:54 AM, Paul Benedict <pbenedict@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 <markt@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message