You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Thomas <ma...@apache.org> on 2011/05/06 12:43:41 UTC
[POOL2] Java 1.5 or 1.6?
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 currently 1.5.
It would make the implementation of the FIFO/LIFO allocation option
considerably easier if that was changed to 1.6.
The options as I see them are:
a) Java 1.5 with FIFO or LIFO allocation
b) Java 1.5 with FIFO allocation only
c) Java 1.6 with FIFO or LIFO allocation
b) & c) are likely to be considerably easier to write since I can use
the classes provided by java.u.c
a) looks like it will be a PITA to write
My preferred option is c)
I think b) is a bad idea since it makes idle object expiration harder
I think a) is a bad idea as I don't want to have to figure out how to
make that work, not do I want to have to maintain it once it is written
as I suspect it will end up being quite complex (although I could be wrong).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
On 5/6/11 5:13 AM, Jochen Wiedmann wrote:
> On Fri, May 6, 2011 at 1:57 PM, sebb <se...@gmail.com> wrote:
>
>> Not all OSes are supported by Sun/Oracle, and not all JVM vendors
>> update their products as quickly.
>>
>> There may still be OSes that don't support Java 1.6 yet.
> They still have pool 1.
>
>
>> Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also?
> At the point when DBCP chooses to use pool 2 and not pool 1 as a
> dependency. No reason to do that now. Due to the binary
> incompatibility, I'd recommend the contrary.
Right. An important additional note is that DBCP 2 will require 1.6
in any case. We discussed earlier and decided to drop JDBC 3
support in DBCP 2 - i.e., there will be only one DBCP 2,x version
and that version will require JDBC 4 so JDK 1.6.
Phil
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Fri, May 6, 2011 at 1:57 PM, sebb <se...@gmail.com> wrote:
> Not all OSes are supported by Sun/Oracle, and not all JVM vendors
> update their products as quickly.
>
> There may still be OSes that don't support Java 1.6 yet.
They still have pool 1.
> Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also?
At the point when DBCP chooses to use pool 2 and not pool 1 as a
dependency. No reason to do that now. Due to the binary
incompatibility, I'd recommend the contrary.
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Mark Thomas <ma...@apache.org>.
On 06/05/2011 12:57, sebb wrote:
> On 6 May 2011 12:26, Jochen Wiedmann <jo...@gmail.com> wrote:
>> +1 for Java 1.6
>>
>> Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even
>> deprecated by Sun/Oracle and we should try to keep things simple.
>>
>
> Not all OSes are supported by Sun/Oracle, and not all JVM vendors
> update their products as quickly.
>
> There may still be OSes that don't support Java 1.6 yet.
>
> I know that OpenVMS tends to lag behind, but they do have Java 1.6 for
> I64 hardware.
> However they don't have 1.6 for Alpha hardware which AFAIK is still
> very much in use.
There is still pool1 and dbcp1 for those users.
> I don't know about IBM OSes - does anyone know about their Java support?
It tends to follow the security updates so should not be an issue. Same
with HP for HPUX.
> Even when new versions of Java are available, many companies take a
> long time to update their systems.
So they aren't going to be using pool2 and dbcp2 either for the same reason.
> Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also?
Yes.
> I'm not saying that we should not use 1.6, but I think we should
> strive to make pool compatible with 1.5 if at all possible.
The only practical way to do that with java.u.c is going to be by
limiting pool to a FIFO queue. I think that is too high a price to pay.
My own view is that LIFO makes more sense for pool so we can more easily
destroy idle objects (although even finding them with the available
java.u.c implementations would be entertaining).
I have done a little more more research and idle object eviction /
validation is going to be complex enough with Java 1.6 since there is no
way to insert back at a particular point in the queue.
At the moment, I am leaning heavily towards requiring 1.6 but the final
decision on that can wait until I have the evictor stuff working.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Simone Tripodi <si...@apache.org>.
+1 to Seb's observations
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, May 6, 2011 at 1:57 PM, sebb <se...@gmail.com> wrote:
> On 6 May 2011 12:26, Jochen Wiedmann <jo...@gmail.com> wrote:
>> +1 for Java 1.6
>>
>> Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even
>> deprecated by Sun/Oracle and we should try to keep things simple.
>>
>
> Not all OSes are supported by Sun/Oracle, and not all JVM vendors
> update their products as quickly.
>
> There may still be OSes that don't support Java 1.6 yet.
>
> I know that OpenVMS tends to lag behind, but they do have Java 1.6 for
> I64 hardware.
> However they don't have 1.6 for Alpha hardware which AFAIK is still
> very much in use.
>
> I don't know about IBM OSes - does anyone know about their Java support?
>
> Even when new versions of Java are available, many companies take a
> long time to update their systems.
>
> Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also?
>
> I'm not saying that we should not use 1.6, but I think we should
> strive to make pool compatible with 1.5 if at all possible.
>
>>
>> On Fri, May 6, 2011 at 12:43 PM, Mark Thomas <ma...@apache.org> 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 currently 1.5.
>>>
>>> It would make the implementation of the FIFO/LIFO allocation option
>>> considerably easier if that was changed to 1.6.
>>>
>>> The options as I see them are:
>>>
>>> a) Java 1.5 with FIFO or LIFO allocation
>>> b) Java 1.5 with FIFO allocation only
>>> c) Java 1.6 with FIFO or LIFO allocation
>>>
>>> b) & c) are likely to be considerably easier to write since I can use
>>> the classes provided by java.u.c
>>> a) looks like it will be a PITA to write
>>>
>>> My preferred option is c)
>>>
>>> I think b) is a bad idea since it makes idle object expiration harder
>>>
>>> I think a) is a bad idea as I don't want to have to figure out how to
>>> make that work, not do I want to have to maintain it once it is written
>>> as I suspect it will end up being quite complex (although I could be wrong).
>>>
>>> Mark
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> I Am What I Am And That's All What I Yam (Popeye)
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by sebb <se...@gmail.com>.
On 6 May 2011 12:26, Jochen Wiedmann <jo...@gmail.com> wrote:
> +1 for Java 1.6
>
> Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even
> deprecated by Sun/Oracle and we should try to keep things simple.
>
Not all OSes are supported by Sun/Oracle, and not all JVM vendors
update their products as quickly.
There may still be OSes that don't support Java 1.6 yet.
I know that OpenVMS tends to lag behind, but they do have Java 1.6 for
I64 hardware.
However they don't have 1.6 for Alpha hardware which AFAIK is still
very much in use.
I don't know about IBM OSes - does anyone know about their Java support?
Even when new versions of Java are available, many companies take a
long time to update their systems.
Also, won't requiring 1.6 for Pool force DBCP to use 1.6 also?
I'm not saying that we should not use 1.6, but I think we should
strive to make pool compatible with 1.5 if at all possible.
>
> On Fri, May 6, 2011 at 12:43 PM, Mark Thomas <ma...@apache.org> 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 currently 1.5.
>>
>> It would make the implementation of the FIFO/LIFO allocation option
>> considerably easier if that was changed to 1.6.
>>
>> The options as I see them are:
>>
>> a) Java 1.5 with FIFO or LIFO allocation
>> b) Java 1.5 with FIFO allocation only
>> c) Java 1.6 with FIFO or LIFO allocation
>>
>> b) & c) are likely to be considerably easier to write since I can use
>> the classes provided by java.u.c
>> a) looks like it will be a PITA to write
>>
>> My preferred option is c)
>>
>> I think b) is a bad idea since it makes idle object expiration harder
>>
>> I think a) is a bad idea as I don't want to have to figure out how to
>> make that work, not do I want to have to maintain it once it is written
>> as I suspect it will end up being quite complex (although I could be wrong).
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> 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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Jochen Wiedmann <jo...@gmail.com>.
+1 for Java 1.6
Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even
deprecated by Sun/Oracle and we should try to keep things simple.
On Fri, May 6, 2011 at 12:43 PM, Mark Thomas <ma...@apache.org> 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 currently 1.5.
>
> It would make the implementation of the FIFO/LIFO allocation option
> considerably easier if that was changed to 1.6.
>
> The options as I see them are:
>
> a) Java 1.5 with FIFO or LIFO allocation
> b) Java 1.5 with FIFO allocation only
> c) Java 1.6 with FIFO or LIFO allocation
>
> b) & c) are likely to be considerably easier to write since I can use
> the classes provided by java.u.c
> a) looks like it will be a PITA to write
>
> My preferred option is c)
>
> I think b) is a bad idea since it makes idle object expiration harder
>
> I think a) is a bad idea as I don't want to have to figure out how to
> make that work, not do I want to have to maintain it once it is written
> as I suspect it will end up being quite complex (although I could be wrong).
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
I Am What I Am And That's All What I Yam (Popeye)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 6, 2011 at 11:54 AM, Paul Benedict <pb...@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 <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-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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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 <pb...@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-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
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
> ---------------------------------------------------------------------
> 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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Simone Tripodi <si...@apache.org>.
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.
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.
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.
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 <ph...@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 <pb...@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-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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
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 <pb...@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-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
>>
>>
> ---------------------------------------------------------------------
> 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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Simone Tripodi <si...@apache.org>.
Honestly, I agree with Paul. Let's release early and often!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, May 6, 2011 at 5:54 PM, Paul Benedict <pb...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by Paul Benedict <pb...@apache.org>.
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-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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
On 5/6/11 8:35 AM, Mark Thomas 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.
>
+1 - let's get it right! See post to follow on robustness, which
may have implications on this (active instance tracking).
>>> 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.
Got it. Lets discuss the options in detail.
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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
On 5/6/11 10:31 AM, sebb wrote:
> On 6 May 2011 16:35, 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.
> I can see why removal of arbitrary entries is needed, but why do we
> need insertion of elements other than at head or tail?
When the Evictor visits an idle instance for validation, it removes
it from the queue (so it does not get handed out to a client while
it is being examined) and then puts it back when validation has been
completed.
>> 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.
This may not be advisable given the potential for "entanglements,"
but a logical option might be to look into bringing in the Harmony
sources for the 1.6 class. Could end up with an intractable mess of
dependencies, but it is a logical option.
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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by sebb <se...@gmail.com>.
On 6 May 2011 16:35, 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.
I can see why removal of arbitrary entries is needed, but why do we
need insertion of elements other than at head or tail?
> 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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Mark Thomas <ma...@apache.org>.
On 06/05/2011 17:00, Honton, Charles wrote:
> Consider ArrayBlockingQueue. It has ability to remove a specified element
> from queue. Also, it is bounded, which is probably desirable.
All queues can remove a specified element (if you know what that element
is). What you can't do (but we could with CursorableLinkedList) is
insert an element at a specific point in the queue.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] Java 1.5 or 1.6?
Posted by "Honton, Charles" <Ch...@intuit.com>.
Consider ArrayBlockingQueue. It has ability to remove a specified element
from queue. Also, it is bounded, which is probably desirable.
Chas
On 5/6/11 11: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-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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Mark Thomas <ma...@apache.org>.
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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Phil Steitz <ph...@gmail.com>.
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?
> 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?
> The options as I see them are:
>
> a) Java 1.5 with FIFO or LIFO allocation
> b) Java 1.5 with FIFO allocation only
> c) Java 1.6 with FIFO or LIFO allocation
>
> b) & c) are likely to be considerably easier to write since I can use
> the classes provided by java.u.c
> a) looks like it will be a PITA to write
>
> My preferred option is c)
>
> I think b) is a bad idea since it makes idle object expiration harder
Right, if there is only one option it should be LIFO (as it was in
pool 1.0-1.2). I think configurability is good.
> I think a) is a bad idea as I don't want to have to figure out how to
> make that work, not do I want to have to maintain it once it is written
> as I suspect it will end up being quite complex (although I could be wrong).
I share sebb's concerns that this is going to leave some users
behind, but they will still have 1.x and it seems a fair expectation
that to get the new version they need to 1.6. This is consistent
with what we are doing in DBCP. So once I understand what the
problem is, I will end up +1 on option c).
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
Re: [POOL2] Java 1.5 or 1.6?
Posted by Gary Gregory <ga...@gmail.com>.
On May 6, 2011, at 6:44, Mark Thomas <ma...@apache.org> 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 currently 1.5.
>
> It would make the implementation of the FIFO/LIFO allocation option
> considerably easier if that was changed to 1.6.
Ok with me +1
Gary
>
> The options as I see them are:
>
> a) Java 1.5 with FIFO or LIFO allocation
> b) Java 1.5 with FIFO allocation only
> c) Java 1.6 with FIFO or LIFO allocation
>
> b) & c) are likely to be considerably easier to write since I can use
> the classes provided by java.u.c
> a) looks like it will be a PITA to write
>
> My preferred option is c)
>
> I think b) is a bad idea since it makes idle object expiration harder
>
> I think a) is a bad idea as I don't want to have to figure out how to
> make that work, not do I want to have to maintain it once it is written
> as I suspect it will end up being quite complex (although I could be wrong).
>
> 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