commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dheeraj Kumar <dksid...@gmail.com>
Subject Re: [pool] Re: Apache Common Pool Road Map
Date Tue, 23 Jun 2009 06:02:38 GMT
On Fri, Jun 19, 2009 at 9:06 AM, Phil Steitz <phil.steitz@gmail.com> wrote:

> Mark Thomas wrote:
>
>> Phil Steitz wrote:
>>
>>
>>> Dheeraj Kumar wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> Congratulations on Pool 1.5.1 release.
>>>>  I was looking for Java 1.5 generics support on Apache Commons Pool and
>>>> found out RoadMap at
>>>> http://wiki.apache.org/jakarta-commons/PoolRoadMap (last edited
>>>> 2006-09-10 02:28:23 by SandyMcArthur). Other than that, bug related to
>>>> this at http://issues.apache.org/jira/browse/POOL-83. I felt, it is
>>>> good time to have another check on this RoadMap and combine release
>>>> track for Pool  2.0 and Pool 3.0. As it will reduce lots of
>>>> development/maintainance efforts. Anyone using JDK below 1.5, will be
>>>> happy with 1.x track, and for JDK 1.5+ user, there will be Pool 2.x.
>>>>
>>>>
>>> Thanks for the feedback.  The roadmap Wiki page definitely needs to be
>>> updated.  I will do that following discussion here.  I agree with
>>> combining the 2.0 and 3.0 tracks, but we need to agree first on what, if
>>> any, behavior changes we implement as part of the next major release.  I
>>> would also like us to continue supporting the 1.x branch for backward
>>> compatibility and pre-JDK 1.5 environments.
>>>
>>> At this point, other than addressing POOL-131,  I am not yet convinced
>>> that we should implement any behavior changes beyond those that were
>>> implemented in pool 1.4.   That is, of course, just my opinion and I am
>>> open to suggestions on contract changes for 2.0.  Does anyone have
>>> specific suggestions for API improvement or comments on the Wiki page?
>>>
>>>
>>
>> Generally, that list looks good.
>>
>> I'd agree we need to add POOL-131/logging. Obviously, that means picking a
>> framework...
>>
>>
> Yes.  Same applies to dbcp and if you look at the archives, the framework
> selection is where we have stalled in the past.  I would really like to get
> this fixed and while it is not really a pure "bugfix" would like to do
> something that could at least back port to a 1.x release.
>
>> I'd also like to look at POOL-142. I understand the point that Sandy makes
>> but
>> it remains that not throwing the exception made writing test cases a lot
>> harder.
>>  Better logging is probably the way to handle this. Back to POOL-131 ;)
>>
>> My other question is what do we do about the code in
>>
>> https://svn.apache.org/repos/asf/commons/proper/pool/branches/2_0_DEV/
>>
>> ?
>>
>> With the recent changes for fairness and removing syncs, I suspect the
>> code has
>> diverged a lot.
>>
>>
> The 2.0 branch was essentially a complete rewrite, so yes, it is
> "different."  I think we really have three alternatives for 2.0:
>
> 1) continue to build on the code in trunk, adding generics support but
> using the same core pooling / thread management code.
> 2) build on the code in the 2.0 branch
> 3) leverage JDK 1.5+ features to develop a new and simpler implementation
>
> I think all are worth looking at.  I lean toward 1), because it makes
> backporting bugfixes easier, means we have less code to maintain, and it
> provides a lot of flexibility and good performance.  I have not thought that
> much about 3) and have not looked at 2) in quite a while.  The downside of
> 1) is that the code is not exactly "inviting."  We have had a hard time
> attracting and retaining a community around pool I think partly because of
> this.  The code is not that easy to follow and the fairness stuff actually
> makes it a little harder.  So if we do go that route, we should think about
> ways to continue to improve the documentation.
>
I will supported 3), Reason being there are totally new data structures in
java.util.concurrent.*, which should be heart of new implementations. We
should also try to keep interfaces similar to Pool 1.X track.

-Dheeraj

>
> Phil
>
>  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
>
>

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