2010/10/17 Phil Steitz
> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>
>> Making pool be able to be resized at runtime will introduce extra
>> complexity, that could be otherwise totally delegated to a BlockingQueue
>> as
>> backend structure.
>>
>
> I don't understand exactly what you are saying
This behavior can also be achieved using the maxIdle parameter :
maxActive : -1 or Integer.MAX
maxIdle : 200 for example
we can thus borrow more than 200 objects, and the 201st will be discarded
once returned to the pool.
So now again, couldn't we achieve the same behavior with only FAIL and BLO
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-pool has an issue affecting its community integration.
This issue
Hi.
[This refers to classes in package "optimization.direct".]
Currently the class "NelderMead" inherits from "DirectSearchOptimizer".
However the method "doOptimize" is _implemented_ in "DirectSearchOptimizer".
This is backwards from the intended design (where an "optimizer" is defined
as a class
On Sun, Oct 17, 2010 at 4:01 PM, Jörg Schaible wrote:
> Hi Niall,
>
> Niall Pemberton wrote:
>
>> I have prepared Commons IO 2.0 RC5. The main changes since RC4 was to
>> rename the FilesystemObserver/Monitor to
>> FileAlterationObserver/Monitor and improvements to the test coverage.
>>
>> The RC3
On Sat, Oct 16, 2010 at 9:56 AM, Dennis Lundberg wrote:
> When you say consistent, what are you referring to? The fact that lang
> has done it once?
>
> It is not the Maven way to change the artifactId when a new major
> version comes out. And since we are talking about the Maven
> "coordinates" (
On 10/17/10 2:58 PM, Gary Gregory wrote:
Shouldnt we talk more across these two projects? Perhaps making sure we have
good reuse and cross pollination
Commons is *one* project. That said, the answer is obviously yes.
As we start to bring in the jdbc-pool stuff, this will become even
more ap
Shouldnt we talk more across these two projects? Perhaps making sure we have
good reuse and cross pollination
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.ap
Hi folks,
the vote to release commons-exec-1.1 based on RC1 resulted in 7 binding
+1 votes
+) Oliver Heger (binding)
+) Niall Pemberton (binding)
+) Rahul Akolkar (binding)
+) Sebastian Bazley (binding)
+) Henri Biestro (binding)
+) Jörg Schaible (binding)
+) Siegfried Goeschl (binding)
Cheer
With Shane's permission, I am forwarding this so we can all join in
the fun :)
I have just started to review the material in the link below and I
think we are by in large in pretty good shape, but the main site and
some of the component sites may need some tweaking to make sure all
the links
On Sun, Oct 17, 2010 at 1:20 PM, Phil Steitz wrote:
>
> Yes, but the question is do you really *need* this option, since setting
> maxActive = -1 effectively accomplishes the same thing.
>
Not exactly. The distinction between the two approaches would be more
obvious at return object time. With
On 10/17/10 12:38 PM, James Carman wrote:
On Sun, Oct 17, 2010 at 12:38 PM, James Carman
wrote:
From the Javadocs for GenericObjectPool:
"when the pool is exhausted (i.e., the maximum number of active
objects has been reached), the borrowObject() method should simply
create a new object any
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Sunday, October 17, 2010 05:53
> To: Commons Developers List
> Subject: [COLLECTIONS] Tidy up of test classes
>
> In the process of ensuring that the Ant and Maven builds ran the same
> set of tests, I found some test case
On Sun, Oct 17, 2010 at 12:38 PM, James Carman
wrote:
> From the Javadocs for GenericObjectPool:
>
> "when the pool is exhausted (i.e., the maximum number of active
> objects has been reached), the borrowObject() method should simply
> create a new object anyway. "
>
> So, it's a different case.
>From the Javadocs for GenericObjectPool:
"when the pool is exhausted (i.e., the maximum number of active
objects has been reached), the borrowObject() method should simply
create a new object anyway. "
So, it's a different case. It allows for you to disregard the maximum size.
On Sun, Oct 17,
On 10/17/10 8:37 AM, Benoit Perroud wrote:
I would like to take the opportunity of this discussion around the action
when the pool is exhausted to call for background reflexion about this 3
behaviors :
Is there really 3 behaviors ?
For me GROW is useless, because in both case FAIL or BLOCK, the
It makes perfect sense if you want multiple versions of DBCP on the
classpath. We had that discussion with Lang 3 as well.
Paul
On Sun, Oct 17, 2010 at 10:52 AM, Simone Tripodi
wrote:
> Hi Phil,
> I'm sure the build will be broken at least at the beginning, this
> morning I migrated the commons-
Hi Phil,
I'm sure the build will be broken at least at the beginning, this
morning I migrated the commons-pool pom metadata and package.
Please let me know if I can be helpful on dbcp too, thanks in advance.
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
O
On 10/17/10 8:53 AM, Benoit Perroud wrote:
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
I don't understand exactly what you are saying here. The question
is should the user-expo
Siegfried Goeschl wrote:
> Hi folks,
>
> I would like to call a vote for releasing commons-exec-1.1 based on RC1.
> Below you find the RC coordinates
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Tag:
>
>
https://svn.apache.org/repos/asf/commons/proper/exec/tags/COMMONS_EXEC_1_1_RC1
>
> Site:
On 10/17/10 9:57 AM, Jörg Schaible wrote:
Hi Phil,
Phil Steitz wrote:
I just created a dbcp 1.4 legacy branch, so we can now start work
toward dbcp 2.0 in trunk. Pool is already off to the races. As we
have discussed, I would like to start exploring bringing in the
Tomcat jdbc-pool code, spl
Hi Niall,
Niall Pemberton wrote:
> I have prepared Commons IO 2.0 RC5. The main changes since RC4 was to
> rename the FilesystemObserver/Monitor to
> FileAlterationObserver/Monitor and improvements to the test coverage.
>
> The RC3 changes were improvements to some tests which were causing
> int
sebb wrote:
> In the process of ensuring that the Ant and Maven builds ran the same
> set of tests, I found some test cases weren't being run.
>
> This was mainly due to the inconsistent naming conventions used, as
> well as the use of TestAll classes.
>
> I think it would be a lot simpler to ma
Hi Phil,
Phil Steitz wrote:
> I just created a dbcp 1.4 legacy branch, so we can now start work
> toward dbcp 2.0 in trunk. Pool is already off to the races. As we
> have discussed, I would like to start exploring bringing in the
> Tomcat jdbc-pool code, split somehow between [pool] and [dbcp].
In the process of ensuring that the Ant and Maven builds ran the same
set of tests, I found some test cases weren't being run.
This was mainly due to the inconsistent naming conventions used, as
well as the use of TestAll classes.
I think it would be a lot simpler to maintain and understand the t
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?
ArrayBlockingQueue is IMO a good can
I would like to take the opportunity of this discussion around the action
when the pool is exhausted to call for background reflexion about this 3
behaviors :
Is there really 3 behaviors ?
For me GROW is useless, because in both case FAIL or BLOCK, the pool will
GROW from initial size to the MAX
done on trunk, svn history has been preserved.
Have a nice Sunday,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Oct 17, 2010 at 3:11 AM, Phil Steitz wrote:
> On 10/16/10 3:57 PM, Gary Gregory wrote:
>>
>> On Oct 16, 2010, at 10:21, "Phil Steitz" wrote:
>>
>>> O
OK, i've removed the other use of getCause and modified the SimpleDaemon to
use the exception if it can't bind to its server port.
I'm going to have a look and see if I can get the failure message to come
out on stderr, as well as out to the logs (if they are used). Reason being
that if you are ru
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=1145&projectId=71
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 17 Oct 2010 11:20:11 +
Finished at: Sun 17 Oct 2010 11:24:07 +
Total time: 3m 56s
Build Trigger: Schedule
B
30 matches
Mail list logo
