commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject Re: pool: stack, cycle and eviction
Date Wed, 31 May 2006 06:30:21 GMT
On 5/31/06, Tom <tbee@tbee.org> wrote:
> >> Since the sequence of objects in the stack is random,
> >
> > Umm, that statement is incorrect. The idle objects in a stack based
> > pool would have the stalest objects on the bottom. It may be random
> > with respect to the order the object were created but the order with
> > respect to when they were returned is very specific.
> Correct, I did mean random in light of the usage of the object; it is
> not like one object is borrowed preferred over another because of, say,
> better performance. The pool has no feedback logic where objects
> associated with lesser burdened resources have a higher borrow priority
> - if you get what I mean - of course there is an ordering according to
> "staleness" possible. Hmmmm, it would be an interesting add-on to the
> pool though, callbacks so the objects can be prioritized.

Hrm, pass the pool a Comparator and let it keep the internal idle
object list sorted. But really any valid idle object should be just as
good as any other valid idle object. I don't think you'd gain anything
in the real world.

> > Now, this deadlock issue goes away if the Pool never calls out to the
> > PoolableObjectFactory methods while it is holding it's internal
> > "PoolLock".
> I totally believe you :-) What the hell am I talking about? I don't know
> the source code at all. And I forgot to thank the developers for a great
> library!

I don't know either.

> > Personally, I think the composite pool code in the trunk is quite
> > robust and solid. The current problem is it is not really any faster
> > than the existing pool implementations.
>
> Hm. Good to hear, I'll take a peak. Is performance an issue?

Yes and no. Pool itself rarely uses even 1% of cpu time for a request
in a webapp. But since it's a bottleneck, especially when new objects
need to be made that take a while to create (such as a connection to a
DB), it can introduce latency and hold up a number of requests while
they wait to borrow/return objects to/from the pool. End users tend to
care about responsiveness measured by wall clock time over raw cpu
time.

Currently pool has a rather flat throughput curve as you add more
CPUs. At work when we pay for quad cpu servers we want them to have an
almost 4x performance over a single CPU server. Any code that gives
less than a 2x performance increase for 4x the hardware is
disappointing.

> > I may punt this until Pool 3.0 where we require Java 5 and
> > the java.util.concurrent classes are available.
> Hm. Personally I love Java 5, but I can't seem to get all my clients to
> move. Forcing the pool library to 1.5 will probaby mean a lot of
> projects cannot follow.

My personal rule of thumb is to target two releases back from the
current stable JVM.

> Would using the original locking library (or
> -dare I say-  embedding one or a few classes from that library) be an
> option?

Don't know, haven't looked into it or the licensing issues yet.

-- 
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message