What about the Cursors? Don't these need to be reset to null as well?
On 02/06/2009, pste...@apache.org wrote:
> Author: psteitz
> Date: Tue Jun 2 02:01:22 2009
> New Revision: 780905
>
> URL: http://svn.apache.org/viewvc?rev=780905&view=rev
> Log:
> Ensure that clear() fully clears the poo
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-math has an issue affecting its community integration.
This issue
On 02/06/2009, Phil Steitz wrote:
>
>
> >
> > > >
> > >
> > >
> > > I just tried using the fixed numbers from a failed run (instead of
> > > using random ones), and it fails every time with the following
> > > settings:
> > >
> > > runs=26
> > > Lengths=12,12,28
> > >
> > > So it's clearly s
Hello,
This change has been implemented as general utility functions and is
used for now only in the linear optimizer package, see LinearObjectiveFunction
and LinearConstraint classes (it should fix a recent Gump failure).
Do others think using these new methods should be generalized to other cl
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-configuration-test has an issue affecting its community
integrati
sebb wrote:
On 02/06/2009, Phil Steitz wrote:
>
I just tried using the fixed numbers from a failed run (instead of
using random ones), and it fails every time with the following
settings:
runs=26
Lengths=12,12,28
So it's clearly some kind of logic error - looks like it occurs
On 02/06/2009, Phil Steitz wrote:
> sebb wrote:
>
> > On 02/06/2009, Phil Steitz wrote:
> >
> >
> > >
> > >
> > > >
> > > > > >
> > > > >
> > > > >
> > > > > I just tried using the fixed numbers from a failed run (instead of
> > > > > using random ones), and it fails every time with the followi
pste...@apache.org wrote:
> Author: psteitz
> Date: Tue Jun 2 02:01:22 2009
> New Revision: 780905
>
> URL: http://svn.apache.org/viewvc?rev=780905&view=rev
> Log:
> Ensure that clear() fully clears the pool.
> @@ -1293,6 +1293,7 @@
> }
> }
> destroy(toDestroy);
Good catch. Yes, needs to by synched (and that could be tricky, with
destroy between). Looks to me like destroy destroys the pairs, but
does not clear the queues (prior to change) and clear clears _poolList
but not _poolMap. Could be I am wrong. I Will look at this some more
this eve.
On 6/2/09, M
Sorry for top-post (degraded client ;)
My understanding - which I guess could be made clearer in tha javadoc
- is that clear is an operation on the *idle instance pool* and does
not affect instances checked out or pending requests (allocation
queue). Therefore, numActive should be unchanged by thi
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-jelly-tags-fmt-test has an issue affecting its community
integrat
Ah, OK, I had not realised the allocation queue was separate.
GOP does not have a numIdle count - it uses _pool.size() - so is probably OK.
GKOP has a _totalIdle field, but it looks like it is being maintained.
I'll try adding getNumIdle() ==0 checks after all clear() method calls.
On 02/06/20
On Thu, May 28, 2009 at 3:07 PM, Christian Grobmeier
wrote:
> On Thu, May 28, 2009 at 9:05 PM, Rahul Akolkar
> wrote:
>> On Thu, May 28, 2009 at 3:00 PM, Christian Grobmeier
>> wrote:
> Is there still any committer interested in releasing JEXL 2.0?
>
I have some interest (I di
Phil Steitz wrote:
> Good catch. Yes, needs to by synched (and that could be tricky, with
> destroy between). Looks to me like destroy destroys the pairs, but
> does not clear the queues (prior to change) and clear clears _poolList
> but not _poolMap. Could be I am wrong. I Will look at this some m
Regarding the new FS API, is it possible to make some of the classes
package private to hide them from the API if they aren't intended to be
used directly? I haven't reviewed the API thoroughly, but at first
glance it looks like VFSURLStreamHandler, VerifiableOutputStream and
HttpOutputStream c
Ted Dunning a écrit :
> I think that packages are nice and all, but commons.math is pretty
> aggressive about balkanizing the name space.
>
> +1 for merging.
Since nobody voiced against the merging, I'm going to merge
decomposition back to the linear package as suggested by Sam, thus
reverting th
I've been running the GKOP and GOP tests repeatedly, and there are
some tests which still fail now and then:
The following test fails regularly:
testThreaded1(org.apache.commons.pool.impl.TestGenericObjectPool)
Time elapsed: 6 sec <<< FAILURE!
junit.framework.AssertionFailedError: Thread 18 fail
+1 thanks.
Are you sure not clearing the queues, map and list on clear is OK?
Could this result in memory leaks in some apps?
On 6/2/09, Mark Thomas wrote:
> Phil Steitz wrote:
>> Good catch. Yes, needs to by synched (and that could be tricky, with
>> destroy between). Looks to me like destroy d
Phil Steitz wrote:
> +1 thanks.
>
> Are you sure not clearing the queues, map and list on clear is OK?
> Could this result in memory leaks in some apps?
I am 99.9% sure that the queues map and list will all be clear at the
end of the clear() method. At least, that was my intention. I'll
re-check
Ralph Goers a écrit :
From what I can gather from this conversation:
a) This is important to only a small group of us.
b) No one is against having CC switch back to Commons Logging.
c) Some are very much against using a facade other than Commons Logging,
for whatever reason.
I did the change
ma...@apache.org wrote:
> Author: markt
> Date: Tue Jun 2 21:01:34 2009
> New Revision: 781166
>
> URL: http://svn.apache.org/viewvc?rev=781166&view=rev
> Log:
> Anything that clears the pool is likely to mess up the eviction cursors. This
> fixes the issue sebb reported with testEvictorVisiting
Hi
Over at Apache MINA, we have voted in Vysper as a subproject. The
Vysper project came with a bunch of code for tracking compliance to a
specification (e.g. RFC) using a set of annotations. it also contains
an APT based tool for producing reports based on these annotations.
Here's the current co
On Jun 2, 2009, at 11:23 AM, Emmanuel Bourg wrote:
Regarding the new FS API, is it possible to make some of the classes
package private to hide them from the API if they aren't intended to
be used directly? I haven't reviewed the API thoroughly, but at
first glance it looks like VFSURLStre
On 02/06/2009, Mark Thomas wrote:
> ma...@apache.org wrote:
> > Author: markt
> > Date: Tue Jun 2 21:01:34 2009
> > New Revision: 781166
> >
> > URL: http://svn.apache.org/viewvc?rev=781166&view=rev
> > Log:
> > Anything that clears the pool is likely to mess up the eviction cursors.
> Th
Mark Thomas wrote:
Phil Steitz wrote:
+1 thanks.
Are you sure not clearing the queues, map and list on clear is OK?
Could this result in memory leaks in some apps?
I am 99.9% sure that the queues map and list will all be clear at the
end of the clear() method. At least, that was my in
On Jun 2, 2009, at 1:48 PM, Emmanuel Bourg wrote:
Ralph Goers a écrit :
From what I can gather from this conversation:
a) This is important to only a small group of us.
b) No one is against having CC switch back to Commons Logging.
c) Some are very much against using a facade other than Commo
On 02/06/2009, Niklas Gustavsson wrote:
> Hi
>
> Over at Apache MINA, we have voted in Vysper as a subproject. The
> Vysper project came with a bunch of code for tracking compliance to a
> specification (e.g. RFC) using a set of annotations. it also contains
> an APT based tool for producing r
Phil Steitz wrote:
> Mark Thomas wrote:
>> Phil Steitz wrote:
>>
>>> +1 thanks.
>>>
>>> Are you sure not clearing the queues, map and list on clear is OK?
>>> Could this result in memory leaks in some apps?
>>>
>>
>> I am 99.9% sure that the queues map and list will all be clear at the
>> en
sebb wrote:
> On 02/06/2009, Mark Thomas wrote:
>> ma...@apache.org wrote:
>> > Author: markt
>> > Date: Tue Jun 2 21:01:34 2009
>> > New Revision: 781166
>> >
>> > URL: http://svn.apache.org/viewvc?rev=781166&view=rev
>> > Log:
>> > Anything that clears the pool is likely to mess up the e
29 matches
Mail list logo
