Re: [POOL-279] Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

On Oct 6, 2014, at 2:31 AM, sebb wrote: >> The only way to do it is to make >> lastReturnTime field thread-safe using locks. > > Volatile does make the field thread-safe. > It's just a question of whether the JVM can re-order the statements > when volatile is used. I think Xavier's comments ar

[VOTE] Release Commons Compress 1.9 Based on RC1

Hi all, nothing big this time but a few accumulated bug fixes and support for raw DEFLATE streams. Compress 1.9 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 6728) Maven artifacts are here: https://repository.apache.org/

Re: [POOL-279] Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

On 5 October 2014 23:39, Xavier Detant wrote: > Hello, > > I'm afraid the fix is wrong since, as Bernd said, no JMM property is used. > The JVM is allowed to reorder statments and inlining statments. I'd forgotten about re-ordering. > The volatile keyword assure you to have the most «fresh» valu

Re: [POOL-279] Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

Hello, I'm afraid the fix is wrong since, as Bernd said, no JMM property is used. The JVM is allowed to reorder statments and inlining statments. The volatile keyword assure you to have the most «fresh» value at the moment of the reading, but since the System.currentTimeMillis() has no side effect

[math] SynchronizedDescriptiveStatistics - Instead of using synchronized should we use read/write locks

I see that this class and other SynchronizedSummaryStatistic class is using old style synchronized which synchronizes both reads and writes...so was wondering if we should switch to locks for better concurrency on reads Does any one have a concern if i make this change -Murthy

[math] when is 3.4 release scheduled.

Hi I would like to know when is 3.4 math is scheduled for the release Please let me know. thanks murthy

Re: [POOL-279] Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

On 5 October 2014 13:13, Bernd wrote: > Hmm, > > I am not sure about this, the local variable fetch does not use any > property of the Java Memory Model to make it gurantee to work. That's not the issue - see my recent update to the JIRA. > I would > simply return 0 if the difference is negative

[POOL-279] Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

Hmm, I am not sure about this, the local variable fetch does not use any property of the Java Memory Model to make it gurantee to work. I would simply return 0 if the difference is negative. And of course making the last used value volatile. Greetings Bernd BTW: for what is that idle time used?