On Oct 2, 2014, at 7:24 PM, Mark Thomas wrote:
>> 2) removed an if block that was unnecessary
I have also create a ticket for this and another code cleanup:
https://issues.apache.org/jira/browse/POOL-280
Regards,
Jacopo
-
T
On Oct 2, 2014, at 7:24 PM, Mark Thomas wrote:
> On 02/10/2014 18:00, Jacopo Cappellato wrote:
>> Thank you Phil and Gary for the responses.
>>
>> Phil, the approach you described makes sense to me and I agree: even if part
>> of the fields of DefaultPooledObject are not formally thread-safe,
On 2 October 2014 18:48, Jacopo Cappellato wrote:
>
> On Oct 2, 2014, at 7:24 PM, Mark Thomas wrote:
>
>>> @@ -311,12 +310,8 @@
>>> // Override getMessage to avoid creating objects and formatting
>>> // dates unless the log message will actually be used.
>>> @Override
>>>
On Oct 2, 2014, at 7:24 PM, Mark Thomas wrote:
>> @@ -311,12 +310,8 @@
>> // Override getMessage to avoid creating objects and formatting
>> // dates unless the log message will actually be used.
>> @Override
>> -public String getMessage() {
>> -String
On 02/10/2014 18:00, Jacopo Cappellato wrote:
> Thank you Phil and Gary for the responses.
>
> Phil, the approach you described makes sense to me and I agree: even if part
> of the fields of DefaultPooledObject are not formally thread-safe, the state
> transitions are preserved and this is the m
Thank you Phil and Gary for the responses.
Phil, the approach you described makes sense to me and I agree: even if part of
the fields of DefaultPooledObject are not formally thread-safe, the state
transitions are preserved and this is the most important function of this class.
I understand that
On 9/27/14 10:16 AM, Jacopo Cappellato wrote:
> On Sep 27, 2014, at 6:46 PM, Gary Gregory wrote:
>
>> It is not enough to set them volatile because the class has some invariants
>> that include more than one field.
> For example, under unlucky thread concurrency the method getIdleTimeMillis()
>
On Sep 27, 2014, at 6:46 PM, Gary Gregory wrote:
> It is not enough to set them volatile because the class has some invariants
> that include more than one field.
For example, under unlucky thread concurrency the method getIdleTimeMillis()
could return a negative value.
Jacopo
---
On 9/27/14 6:04 AM, Gary Gregory wrote:
> In org.apache.commons.pool2.impl.DefaultPooledObject.getActiveTimeMillis(),
> I see:
>
> // Take copies to avoid threading issues
> long rTime = lastReturnTime;
> long bTime = lastBorrowTime;
>
> But isn't is the case that the object
ato
> Date:09/27/2014 12:36 (GMT-05:00)
> To: Commons Developers List
> Subject: Re: [pool] time to cut 2.3
>
> Hi Gary, all,
>
> I am sorry if I jump in in this conversation: I am a committer of another ASF
> project (I am actually the PMC chairman for Apache OFBiz) and
Hi and thanks for chiming in.
The best path is to use Jira so we can all look and discuss.
Gary
Original message
From: Jacopo Cappellato
Date:09/27/2014 12:36 (GMT-05:00)
To: Commons Developers List
Subject: Re: [pool] time to cut 2.3
Hi Gary, all,
I am sorry if I jump in
Hi Gary, all,
I am sorry if I jump in in this conversation: I am a committer of another ASF
project (I am actually the PMC chairman for Apache OFBiz) and my project is
using dbcp2/pool2, so thank you for all the work you did and are doing.
I am reviewing the code in DefaultPooledObject and Gary
In org.apache.commons.pool2.impl.DefaultPooledObject.getActiveTimeMillis(),
I see:
// Take copies to avoid threading issues
long rTime = lastReturnTime;
long bTime = lastBorrowTime;
But isn't is the case that the object could be returned and borrowed again
between the two
We have fixed a few bugs and made some enhancements since 2.2 and I
think we should cut 2.3. I will volunteer to RM. I will start
rolling RCs from trunk around the end of this week. I don't see any
of the current open bugs against 2.x as blockers. I may implement
the request in POOL-272 (or gla
14 matches
Mail list logo
