Looks like this is fixed now. I changed the maven build to depend
on pool2 snapshot and Continuum seems to be able to find the locally
installed snap. I also changed the Ant build and Gump metadata, so
Gump appears happy for now as well.
To build dbcp2 using maven, you need to first install a po
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp2 has an issue affecting its community integration.
This issue
On 5/6/11 10:55 AM, Phil Steitz wrote:
> OK. This is getting annoying (and not just for us). I am not sure
> how exactly we got this fixed for [pool] but a simple way to fix it
> is to change the commons-proper metadata to point to the 1.x
> branch. I think pool was fixed differently, but I don'
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=8040&projectId=73
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 6 May 2011 21:23:08 +
Finished at: Fri 6 May 2011 21:23:23 +
Total time: 14s
Build Trigger: Schedule
Build
OK. This is getting annoying (and not just for us). I am not sure
how exactly we got this fixed for [pool] but a simple way to fix it
is to change the commons-proper metadata to point to the 1.x
branch. I think pool was fixed differently, but I don't no how to
get the dependencies redirected. D
On 5/6/11 10:31 AM, sebb wrote:
> On 6 May 2011 16:35, 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 wh
On 6 May 2011 18:16, Mark Thomas wrote:
> On 06/05/2011 17:55, Phil Steitz wrote:
>> There are lots of things to consider in making DBCP manageable in
>> the sense described above. I am starting this discussion now
>> because I want to make sure that we build whatever we need to build
>> into poo
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! - l
On 6 May 2011 16:35, 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 target
On 06/05/2011 17:55, Phil Steitz wrote:
> There are lots of things to consider in making DBCP manageable in
> the sense described above. I am starting this discussion now
> because I want to make sure that we build whatever we need to build
> into pool 2 to make these features possible in DBCP 2.
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 wi
Despite lots of user requests over the years, DBCP has always backed
off the challenge of providing really robust connection pooling -
i.e., seamlessly handling server or network failures. The reason
for this is that from the vantage point of DBCP, doing more than
just validating connections and d
On Fri, May 6, 2011 at 11:54 AM, Paul Benedict 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
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 ofte
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
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" 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
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
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 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 targ
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 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 r
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
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
On Fri, May 6, 2011 at 10:03 AM, sebb wrote:
> On 6 May 2011 14:41, Gary Gregory wrote:
> > On Fri, May 6, 2011 at 5:06 AM, sebb wrote:
> >
> >> On 6 May 2011 09:28, sebb wrote:
> >> > On 6 May 2011 03:06, Gary Gregory wrote:
> >> >> On Thu, May 5, 2011 at 4:19 PM, Gary Gregory >
> >> wrote:
On 5/6/11 5:13 AM, Jochen Wiedmann wrote:
> On Fri, May 6, 2011 at 1:57 PM, sebb 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,
On 6 May 2011 14:41, Gary Gregory wrote:
> On Fri, May 6, 2011 at 5:06 AM, sebb wrote:
>
>> On 6 May 2011 09:28, sebb wrote:
>> > On 6 May 2011 03:06, Gary Gregory wrote:
>> >> On Thu, May 5, 2011 at 4:19 PM, Gary Gregory
>> wrote:
>> >>
>> >>> On Thu, May 5, 2011 at 3:40 PM, sebb wrote:
>> >
On Fri, May 6, 2011 at 5:06 AM, sebb wrote:
> On 6 May 2011 09:28, sebb wrote:
> > On 6 May 2011 03:06, Gary Gregory wrote:
> >> On Thu, May 5, 2011 at 4:19 PM, Gary Gregory
> wrote:
> >>
> >>> On Thu, May 5, 2011 at 3:40 PM, sebb wrote:
> >>>
> On 5 May 2011 20:21, Gary Gregory wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp has an issue affecting its community integration.
This issue
+1 to Seb's observations
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, May 6, 2011 at 1:57 PM, sebb wrote:
> On 6 May 2011 12:26, Jochen Wiedmann wrote:
>> +1 for Java 1.6
>>
>> Java 1.6 is now 5 years old, Java 1.5 is officially obsolete, or even
>> deprecated by Su
On Fri, May 6, 2011 at 1:57 PM, sebb 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 al
On 06/05/2011 12:57, sebb wrote:
> On 6 May 2011 12:26, Jochen Wiedmann 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 n
On 6 May 2011 12:26, Jochen Wiedmann 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
On May 6, 2011, at 6:44, 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 currently 1.5.
>
> It would make the implementation
+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 wrote:
> Before I go too far down the road of the re-writing the core object
> allocation code fo
On 05/05/2011 19:08, Phil Steitz wrote:
> Re performance, don't forget to add something that skips the synch
> in createDataSource - i.e., use a PoolingDataSource directly to
> avoid the thread lineup on getConnection due to that internal synch.
Just tested that locally. It doesn't help that much.
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
Hi Mark,
I'm not j.u.c guru but if you're pleased to share your thoughts, I
would be glad to provide at least feedbacks.
Looking forward to see j.u.c. in action in pool, thanks for taking care of it!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, M
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=8023&projectId=73
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 6 May 2011 09:24:03 +
Finished at: Fri 6 May 2011 09:24:17 +
Total time: 14s
Build Trigger: Schedule
Build
On 6 May 2011 09:28, sebb wrote:
> On 6 May 2011 03:06, Gary Gregory wrote:
>> On Thu, May 5, 2011 at 4:19 PM, Gary Gregory wrote:
>>
>>> On Thu, May 5, 2011 at 3:40 PM, sebb wrote:
>>>
On 5 May 2011 20:21, Gary Gregory wrote:
> On Thu, May 5, 2011 at 3:04 PM, sebb wrote:
>
>>>
Here's the failure details:
Testcase: testNext(org.apache.commons.math.random.EmpiricalDistributionTest):
FAILED
mean expected:<5.172236421316645> but was:<5.069831575018909>
junit.framework.AssertionFailedError: mean
expected:<5.172236421316645> but was:<5.069831575018909>
at
org.apac
On 6 May 2011 03:06, Gary Gregory wrote:
> On Thu, May 5, 2011 at 4:19 PM, Gary Gregory wrote:
>
>> On Thu, May 5, 2011 at 3:40 PM, sebb wrote:
>>
>>> On 5 May 2011 20:21, Gary Gregory wrote:
>>> > On Thu, May 5, 2011 at 3:04 PM, sebb wrote:
>>> >
>>> >> On 5 May 2011 19:39, Gary Gregory wrot
41 matches
Mail list logo
