Hi!
> 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using
> the default SoftRefFilesCache because it doesn't allow background threads.
> I 've found a few really old messages saying things like "SoftRefFilesCache
> is the only implementation suitable for production use" and "o
On May 25, 2009, at 7:10 PM, Vince Bonfanti wrote:
I'm working on a Google App Engine/Java (GAE/J) plug-in for VFS
(it's almost
done) and have a few questions:
1. Is the LRUFilesCache safe for production use? GAE/J won't allow
using
the default SoftRefFilesCache because it doesn't allow ba
-_allocationQueue.removeFirst();
+_allocationQueue.remove(latch);
both places in allocate() makes the problem go away. I am not sure that
is a good fix, but it eliminates the problem. Must have something to do
with the latch notifies. I also don't full
I'm working on a Google App Engine/Java (GAE/J) plug-in for VFS (it's almost
done) and have a few questions:
1. Is the LRUFilesCache safe for production use? GAE/J won't allow using
the default SoftRefFilesCache because it doesn't allow background threads.
I've found a few really old messages say
On 25/05/2009, Phil Steitz wrote:
> Going once, going twice...
>
> Anyone have a problem with this?
OK by me, as there is an Ant build for testing with Java 1.3.
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.
On 25/05/2009, Henri Yandell wrote:
> On Sat, May 23, 2009 at 3:33 AM, sebb wrote:
> > On 23/05/2009, Henri Yandell wrote:
>
>
> >> Maven release plugin is the one doing the copy to the branch. So I
> >> don't see the commit message (well.. it's probably somewhere in the
> >> huge load of t
- Original Message -
From: "Ted Dunning"
To: "Commons Developers List"
Sent: Monday, May 25, 2009 4:52 PM
Subject: Re: [math] Serialization
This sounds like the germ of a repair process.
Nuke all Serializable declarations without test cases. Then, add them
back
where people care
When I do this
// Second utilise any spare capacity to create new objects
if ((_maxActive < 0 || pool.activeCount +
pool.internalProcessingCount < _maxActive) &&
(_maxTotal < 0 || _totalActive + _totalIdle +
_totalInternalProcessing < _maxTota
This sounds like the germ of a repair process.
Nuke all Serializable declarations without test cases. Then, add them back
where people care enough to guarantee correctness by demonstrating a correct
round trip.
On Mon, May 25, 2009 at 4:32 PM, Bill Barker wrote:
> But again, want to ask advice
- Original Message -
From: "Luc Maisonobe"
To: "Commons Developers List"
Sent: Monday, May 25, 2009 12:39 PM
Subject: Re: [math] Serialization
Bill Barker a écrit :
Ok, most of the rest look like transient classes (e.g. all of
linear.decomposition). So asking for what needs to be
- Original Message -
From: "Ted Dunning"
To: "Commons Developers List"
Sent: Sunday, May 24, 2009 11:47 PM
Subject: Re: [math] Serialization
Bill,
Did you commit those changes?
Yes, but just for o.a.c.m.linear.
I ask because I see similar issues with abstract and static classe
Mark Thomas wrote:
Phil Steitz wrote:
I just saw this in one of my load tests
[java] java.util.NoSuchElementException
[java] at java.util.LinkedList.remove(LinkedList.java:644)
[java] at java.util.LinkedList.removeFirst(LinkedList.java:134)
[java] at
org.apache.common
Bill Barker a écrit :
> Ok, most of the rest look like transient classes (e.g. all of
> linear.decomposition). So asking for what needs to be Serialized, and
> what doesn't.
As the main developer of the decomposition package, I can say the
reasons for having these classes Serializable are the sam
Phil Steitz wrote:
> I just saw this in one of my load tests
>
> [java] java.util.NoSuchElementException
> [java] at java.util.LinkedList.remove(LinkedList.java:644)
> [java] at java.util.LinkedList.removeFirst(LinkedList.java:134)
> [java] at
> org.apache.commons.pool.impl
vmware is known to do funny things with timing. Assm this is one of
those, per comment in the test case.
contin...@vmbuild.apache.org wrote:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=193279&projectId=116
Build statistics:
State: Failed
Previous State:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=193279&projectId=116
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 25 May 2009 08:34:39 -0700
Finished at: Mon 25 May 2009 08:36:44 -0700
Total time: 2m 5s
Build Trigger: Schedule
Bui
I just saw this in one of my load tests
[java] java.util.NoSuchElementException
[java] at java.util.LinkedList.remove(LinkedList.java:644)
[java] at java.util.LinkedList.removeFirst(LinkedList.java:134)
[java] at
org.apache.commons.pool.impl.GenericKeyedObjectPool.allocat
Going once, going twice...
Anyone have a problem with this?
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
I realize this thread went the wrong direction.
Why the green? Just noticed Taglibs has the same problem (it uses the
Commons CSS :) ). Very ugly. Presumably we used to use a different
colour and the CSS has been changed?
Hen
On Fri, May 22, 2009 at 4:08 AM, sebb wrote:
> On 22/05/2009, Christi
Mark Thomas wrote:
> Phil Steitz wrote:
>> I added (but have not yet committed) the following test case to validate
>> the WHEN_EXHAUSTED_GROW contract.
>>
>> public void testWhenExhaustedGrow() throws Exception {
>>pool.setMaxActive(1);
>>pool.setMaxTotal(1);
>>pool.setWhen
On Sat, May 23, 2009 at 3:33 AM, sebb wrote:
> On 23/05/2009, Henri Yandell wrote:
>> Maven release plugin is the one doing the copy to the branch. So I
>> don't see the commit message (well.. it's probably somewhere in the
>> huge load of text that passes through). It also changes things befo
Phil Steitz wrote:
> I added (but have not yet committed) the following test case to validate
> the WHEN_EXHAUSTED_GROW contract.
>
> public void testWhenExhaustedGrow() throws Exception {
>pool.setMaxActive(1);
>pool.setMaxTotal(1);
>pool.setWhenExhaustedAction(GenericObje
22 matches
Mail list logo
