[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492251#comment-13492251
]
Thomas Vandahl commented on JCS-73:
---
The patch is not required at my place. What JDK did you use?
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-1.4-dev
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492262#comment-13492262
]
Alexander Kleymenov commented on JCS-73:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode)
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-1.4-dev
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[
https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492344#comment-13492344
]
Thomas Neidhart commented on POOL-213:
--
I tested the described scenario with the latest trunk version (2.0-SNAPSHOT),
and the behavior is now different:
{noformat}
@Test
public void testNumActive() throws Exception {
pool.setMaxTotal(10);
Object o = null;
for (int i = 0; i < 10; i++) {
o = pool.borrowObject();
}
System.out.println(pool.getNumActive());
for (int i = 0; i < 11; i++) {
pool.invalidateObject(o);
}
System.out.println(pool.getNumActive());
}
{noformat}
An exception is thrown when trying to invalidate an object that has already
been removed from the pool.
Though, there may be a possible race condition in the current invalidateObject
method when different threads try to invalidate the same object, as the method
provides no synchronization at all.
In POOL-125 it is mentioned that this problem has been solved, but I fail to
see how this is done for the re-factored version.
> _numActive can go negative
> --
>
> Key: POOL-213
> URL: https://issues.apache.org/jira/browse/POOL-213
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Mark Mindenhall
>
> I'm working on a project that uses Hector (Cassandra client). Hector uses
> commons-pool (we're using 1.5.4) to pool connections to hosts within a
> Cassandra cluster. Hector provides a JMX MBean that exposes a "NumActive"
> property, which is the cumulative call to retrieve numActive from all of the
> individual connection pools. When querying this property via JMS on our
> production servers, we often see negative values. For example, on a server
> that has three connection pools, the "NumActive" property reported was -3899.
> I know this issue has been reported before (POOL-29), and was supposedly
> fixed. The fix discussed there was to merely check the value of _numActive
> to prevent it from going negative. However, that does not fix the real
> problem here, which is that it is possible to decrement _numActive more than
> once for each activated object.
> For example, from a quick look at the code (GenericObjectPool.java, v1.5.4),
> it would be possible to do the following:
> 1) Create a pool with 10 objects.
> 2) Borrow all 10 objects from the pool.
> 3) Call getNumActive (returns 10).
> 4) Call invalidateObject for ONE of the objects 11 times.
> 5) Call getNumActive (returns -1).
> The invalidateObject method calls the _factory to destroy the object, and
> subsequent calls to destroy the same object may or may not result in an
> exception. Regardless, _numActive is decremented within a finally block, and
> therefore would always be decremented even if the object had already been
> invalidated and destroyed.
> I'd like to suggest using a HashSet instead of a counter to keep track of
> active objects. If borrowing an object added it to a HashSet, and returning
> or invaliding the object removed it from the HashSet (subsequent removes
> would be no-ops), the example given above would not result in an incorrect
> value when getNumActive is called (it would just return the current size of
> the HashSet).
> Note that although unrelated to this bug, it might also be wise to use a
> HashSet instead of the int counter _numInternalProcessing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492347#comment-13492347
]
Thomas Vandahl commented on JCS-73:
---
My Java version is
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-10M3909)
Java HotSpot(TM) Client VM (build 20.12-b01-434, mixed mode)
I can build JCS without the patch just fine.
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-2.0.0
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492352#comment-13492352
]
Thomas Vandahl commented on JCS-73:
---
I have difficulties to understand the output of the Groovy script. I see
outputs that I cannot correlate to the source I see. Like this:
ERROR: for 8204 in Thread-9
ERROR STILL PERSISTS for 8204 in Thread-9
ERROR STILL PERSISTS for 8204 in Thread-9
ERROR STILL PERSISTS for 8204 in Thread-9
ERROR STILL PERSISTS for 8204 in Thread-9
ERROR STILL PERSISTS for 8204 in Thread-9
or this
ERROR: for 521 in Thread-11
ERROR STILL PERSISTS for 521 in Thread-11
ERROR FIXED for 521: [value:[a:1, b:2, c:3], aux:[1:a, 2:b, 3:c, t:Thread-8]]
Thread-11
Could you explain why this happens?
BTW: As I see it, the unit test IndexedDiskCacheConcurrentUnitTest employs the
same test pattern but succeeds. Do you know why?
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-2.0.0
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-369) Exception when using SharedPoolDataSource concurrently
[
https://issues.apache.org/jira/browse/DBCP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated DBCP-369:
-
Attachment: DBCP-369.patch
The access to the InstanceKeyObjectFactory is not fully synchronized. Some
methods (registerNewInstance) were already synchronized, while others
(removeInstance, closeAll) not.
This lead to the ConcurrentModificationExceptions when multiple threads try to
modify the internal instanceMap.
The attached patch adds a unit test and fixes the problem by synchronizing all
public/protected methods in the factory that modify / access the instanceMap.
> Exception when using SharedPoolDataSource concurrently
> --
>
> Key: DBCP-369
> URL: https://issues.apache.org/jira/browse/DBCP-369
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Java Hotspot Server VM 1.6.0_07, Linux
>Reporter: Michael Pradel
> Fix For: 1.4.1
>
> Attachments: DBCP-369.patch
>
>
> Hi,
> I get a ConcurrentModificationException when using instances of
> SharedPoolDataSource concurrently. The problem occurs when one thread calls
> setDataSourceName() while another thread calls close(), either on the same
> instance of SharedPoolDataSource or on different instances. I'll attach a
> short example program that leads to an exception for almost every run on my
> machine.
> The cause of the exception seems to be in InstanceKeyObjectFactory.
> registerNewInstance() is synchronized, but removeInstance() isn't. This
> allows concurrent accesses to the non-thread-safe 'instanceMap'.
> Is this a bug? Or are SharedPoolDataSource and InstanceKeyObjectFactory not
> supposed to be thread-safe?
> Thanks!
> import java.util.ArrayList;
> import org.apache.commons.dbcp.datasources.SharedPoolDataSource;
> public class SharedPoolDataSourceTest {
> public static void main(String[] args) {
> new SharedPoolDataSourceTest().run();
> }
>
> private void run() {
> final ArrayList dataSources = new
> ArrayList();
> for (int j = 0; j < 1; j++) {
> SharedPoolDataSource dataSource = new
> SharedPoolDataSource();
> dataSources.add(dataSource);
> }
>
> Thread t1 = new Thread(new Runnable() {
> public void run() {
> for (SharedPoolDataSource dataSource :
> dataSources) {
> dataSource.setDataSourceName("a");
> }
> }
> });
> Thread t2 = new Thread(new Runnable() {
> public void run() {
> for (SharedPoolDataSource dataSource :
> dataSources) {
> try { dataSource.close(); } catch
> (Exception e) {}
> }
>
> }
> });
> t1.start();
> t2.start();
> try {
> t1.join();
> t2.join();
> } catch (InterruptedException ie) {}
> }
> }
> Exception in thread "Thread-0" java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$KeyIterator.next(HashMap.java:828)
> at
> org.apache.commons.dbcp.datasources.InstanceKeyObjectFactory.registerNewInstance(InstanceKeyObjectFactory.java:51)
> at
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.setDataSourceName(InstanceKeyDataSource.java:246)
> at
> potentialBugs.SharedPoolDataSourceTest$1.run(SharedPoolDataSourceTest.java:23)
> at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-372) Statement Leak occurs when batch update is used.
[
https://issues.apache.org/jira/browse/DBCP-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492454#comment-13492454
]
Thomas Neidhart commented on DBCP-372:
--
Indeed, the current passivate method in PoolablePreparedStatement does the
following:
{noformat}
public void passivate() throws SQLException {
_closed = true;
if(_conn != null) {
_conn.removeTrace(this);
}
// The JDBC spec requires that a statement closes any open
// ResultSet's when it is closed.
// FIXME The PreparedStatement we're wrapping should handle this for us.
// See bug 17301 for what could happen when ResultSets are closed twice.
List resultSets = getTrace();
if( resultSets != null) {
ResultSet[] set = resultSets.toArray(new
ResultSet[resultSets.size()]);
for (int i = 0; i < set.length; i++) {
set[i].close();
}
clearTrace();
}
if (batchAdded) {
clearBatch();
}
super.passivate();
}
{noformat}
Thus, indicating that the connection is closed first, and then afterwards
trying to clear any batches. Now the clearBatch method throws an exception if
the connection is already marked as closed.
Imho, the suggested fix would be fine, but we could also change the passivate
method to call clearBatch before setting _closed to true.
> Statement Leak occurs when batch update is used.
>
>
> Key: DBCP-372
> URL: https://issues.apache.org/jira/browse/DBCP-372
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.3, 1.4
> Environment: Oracle 11g
>Reporter: Naozumi Taromaru
>Priority: Critical
> Fix For: 1.4.1
>
>
> org.apache.commons.dbcp.PoolablePreparedStatement#passivate()
> execute clearBatch().
> (DBCP-264)
> But this clearBatch() throw SQLException.
> (DelegatingStatement#checkOpen() throw SQLException, because _closed is true.)
> The result,
> the PoolablePreparedStatement doesn't return to pool, and
> the PoolablePreparedStatement doesn't execute PreparedStatement#close().
> When a lot of data is processed,
> in the case of Oracle
> * ORA-00604
> * ORA-01000
> occurs.
> Proposal:
> "clearBatch();" in passivate() method
> changes as follows.
> batchAdded = false;
> getInnermostDelegate().clearBatch();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-442) HDFS FileSystem Provider
[ https://issues.apache.org/jira/browse/VFS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492485#comment-13492485 ] Gary Gregory commented on VFS-442: -- The patch works for me on Linux. I'll have to disable these tests on Windows and review the patch again. Thank you. > HDFS FileSystem Provider > > > Key: VFS-442 > URL: https://issues.apache.org/jira/browse/VFS-442 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Dave Marion >Priority: Minor > Labels: accumulo, hdfs > Attachments: VFS-442-1.patch, VFS-442-2.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-442) HDFS FileSystem Provider
[ https://issues.apache.org/jira/browse/VFS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-442: - Attachment: vfs-422-3.diff Version 3 of the patch. > HDFS FileSystem Provider > > > Key: VFS-442 > URL: https://issues.apache.org/jira/browse/VFS-442 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Dave Marion >Priority: Minor > Labels: accumulo, hdfs > Attachments: vfs-422-3.diff, VFS-442-1.patch, VFS-442-2.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-442) HDFS FileSystem Provider
[ https://issues.apache.org/jira/browse/VFS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492536#comment-13492536 ] Gary Gregory commented on VFS-442: -- Hello Dave, I've attached version 3 of the patch that: - IMPORTANT: adds HDFS as a provider in providers.xml. - adds missing @Overrides annotations, - makes some ivars final, - makes some vars private, - Edited the Javadoc on the test to say Linux is required. As my previous comment shows, Cygwin on Windows does not work. I cannot run most of the VFS tests in Eclipse due to the way the VFS test framework was coded a long time ago. That's unfortunate, but that's what we have today. I often resort to debugging VFS from Eclipse by connecting to the JVM started by a local Maven run. TO-DOs: # It is still important to provide a test that fits in this framework in addition to the current test. The current test may then become obsolete. # The test needs to be disabled on Windows. It might be best to do that from the POM, which I don't know how to do off the top of my head. JUnit's Assume may be the solution of last resort. # The Maven build creates a "build" directory in the root of the project, that's not good because someone may end up committing it by mistake or including it in a patch (like I almost did). Is this an HDFS store? If so, put it in a folder where the system propoerty java.io.tmpdir points to and remove it at the end of the test. # Some Javadoc comments are missing for public members. # Only make public what must be public. Thank you for your time and contribution! Gary > HDFS FileSystem Provider > > > Key: VFS-442 > URL: https://issues.apache.org/jira/browse/VFS-442 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Dave Marion >Priority: Minor > Labels: accumulo, hdfs > Attachments: vfs-422-3.diff, VFS-442-1.patch, VFS-442-2.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-851) StringUtils.stripEnd("commons-digester.jar", ".jar") returns "commons-digeste" instead of "commons-digester"
Santh Balak created LANG-851:
Summary: StringUtils.stripEnd("commons-digester.jar", ".jar")
returns "commons-digeste" instead of "commons-digester"
Key: LANG-851
URL: https://issues.apache.org/jira/browse/LANG-851
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, jdk 1.5_0_22, jdk 1.6.0_32
Reporter: Santh Balak
StringUtils.stripEnd("commons-digester.jar", ".jar") returns "commons-digeste"
instead of "commons-digester". I tried with all the commons lang versions from
2.1 - 3.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-851) StringUtils.stripEnd("commons-digester.jar", ".jar") returns "commons-digeste" instead of "commons-digester"
[
https://issues.apache.org/jira/browse/LANG-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden resolved LANG-851.
---
Resolution: Won't Fix
Fix Version/s: 3.1
Assignee: Brent Worden
This is the documented behavior of the method. The original reporter wants to
use the
[StringUtils.removeEnd|http://commons.apache.org/lang/api-release/org/apache/commons/lang3/StringUtils.html#removeEnd(java.lang.String,
java.lang.String)] method instead.
> StringUtils.stripEnd("commons-digester.jar", ".jar") returns
> "commons-digeste" instead of "commons-digester"
>
>
> Key: LANG-851
> URL: https://issues.apache.org/jira/browse/LANG-851
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
> Environment: Windows 7, jdk 1.5_0_22, jdk 1.6.0_32
>Reporter: Santh Balak
>Assignee: Brent Worden
> Fix For: 3.1
>
>
> StringUtils.stripEnd("commons-digester.jar", ".jar") returns
> "commons-digeste" instead of "commons-digester". I tried with all the commons
> lang versions from 2.1 - 3.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-513) Extract an interface for hierarchical configurations
[
https://issues.apache.org/jira/browse/CONFIGURATION-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-513.
Resolution: Fixed
Fix Version/s: 2.0
Two new interfaces, {{HierarchicalConfiguration}}, and
{{ImmutableHierarchicalConfiguration}} have been introduced. The original class
{{HierarchicalConfiguration}} has been renamed to
{{BaseHierarchicalConfiguration}}.
I am not that happy with the immutable interface because it is pretty
minimalistic. Unfortunately, it is not even possible to expose the
{{getRootNode()}} method because {{ConfigurationNode}} is mutable. Currently, I
don't have a clever idea how to deal with this.
> Extract an interface for hierarchical configurations
>
>
> Key: CONFIGURATION-513
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-513
> Project: Commons Configuration
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Oliver Heger
> Fix For: 2.0
>
>
> Currently, there is only a class {{HierarchicalConfiguration}} defining the
> API of hierarchical configurations. It would be good to have an interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-512) Add support for immutable configurations
[
https://issues.apache.org/jira/browse/CONFIGURATION-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-512.
Resolution: Fixed
Fix Version/s: 2.0
Interfaces for immutable configurations have been introduced. There are methods
named {{unmodifiableConfiguration()}} in {{ConfigurationUtils}} which allow
creating an immutable view of a regular configuration object.
> Add support for immutable configurations
>
>
> Key: CONFIGURATION-512
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-512
> Project: Commons Configuration
> Issue Type: New Feature
>Affects Versions: 1.9
>Reporter: Oliver Heger
> Fix For: 2.0
>
>
> The {{Configuration}} interface allows manipulating configuration objects.
> There are use cases in which it is not necessary or even forbidden to change
> the content of a Configuration. To support such use cases, a new interface
> {{ImmutableConfiguration}} should be introduced which allows only querying of
> configuration data. In addition, it should be possible to transform a mutable
> configuration into an immutable one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EMAIL-120) attach(DataSource xx) doesn't close inputstream
[
https://issues.apache.org/jira/browse/EMAIL-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved EMAIL-120.
---
Resolution: Fixed
Fix Version/s: 1.3
Fixed in r1406832.
Thanks for the report!
> attach(DataSource xx) doesn't close inputstream
> ---
>
> Key: EMAIL-120
> URL: https://issues.apache.org/jira/browse/EMAIL-120
> Project: Commons Email
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows 7, 64 bit
>Reporter: mike bell
> Fix For: 1.3
>
>
> Basically I have code like shown below.
> message.attach(reports[1].getDatasource(),
>
> "Report" + new
> SimpleDateFormat("mmdd").format(new java.util.Date()) + "." +
> selectedAttachment,
> selectedAttachment.toUpperCase() + " version of
> report");
> Where the DataSource in question is a simple JAF FileDataSource.
> What I found [when I found files were not being cleaned up by my cleaner)
> 1. I can delete the backing file before calling this method
> 2. I cannot delete the backing file after calling this method.
> 3. Workaround uses the URL version of attachment.
> DataSource ds=reports[1].getDatasource();
> FileDataSource fds=(FileDataSource) ds;
> URL url=fds.getFile().toURI().toURL();
>
> /**
>* MJB: We don't use the DataSource directly (as we
> should) because of a bug in Commons Email
>* where it usually doesn't close the inputstream
>*/
> message.attach(url,"Report" + new
> SimpleDateFormat("mmdd").format(new java.util.Date()) + "." +
> selectedAttachment,
> selectedAttachment.toUpperCase() + "
> version of report");
> 4. I therefore assume the inputstream has been opened and never closed.
> 5. Same test after calling send() provides same results
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-68) Donation/Proposal for Commons-Email 2.0
[ https://issues.apache.org/jira/browse/EMAIL-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492759#comment-13492759 ] Thomas Neidhart commented on EMAIL-68: -- A few things I would like to see in commons-email 2.0 * fluent api * maven compliant structure * move to junit 4 > Donation/Proposal for Commons-Email 2.0 > --- > > Key: EMAIL-68 > URL: https://issues.apache.org/jira/browse/EMAIL-68 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Ramiro Pereira de Magalhães > Fix For: 2.0 > > Attachments: commons.email2.zip > > > This is a donation of code to the commons-email project. I hope it inspires > people to create a more flexible, extensible and maintainable API for sending > e-mail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
[ https://issues.apache.org/jira/browse/EMAIL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated EMAIL-118: -- Fix Version/s: 2.0 > smtpPort setter and getter doesn't works with the same type in EmailClass > - > > Key: EMAIL-118 > URL: https://issues.apache.org/jira/browse/EMAIL-118 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Xavier Detant >Priority: Trivial > Labels: patch > Fix For: 2.0 > > Attachments: SmtpAsInt.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > The smtpPort in the Email class can be set as an int but is get as a String. > This is quite bad design, the getter and the setter should works with the > same type. As smtp ports is a number, the getter which is currently _public > String getSmtpPort()_ should be _public int getSmtpPort()_: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
[ https://issues.apache.org/jira/browse/EMAIL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492765#comment-13492765 ] Thomas Neidhart commented on EMAIL-118: --- Pushing to 2.0 as it would break compatibility. Looking at the code, it is not quite clear why the port is actually stored as a String. It is put into the Session object, which requires a String value, but it could also be converted for this purpose. The same btw applies also to the sslSmtpPort property. > smtpPort setter and getter doesn't works with the same type in EmailClass > - > > Key: EMAIL-118 > URL: https://issues.apache.org/jira/browse/EMAIL-118 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Xavier Detant >Priority: Trivial > Labels: patch > Fix For: 2.0 > > Attachments: SmtpAsInt.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > The smtpPort in the Email class can be set as an int but is get as a String. > This is quite bad design, the getter and the setter should works with the > same type. As smtp ports is a number, the getter which is currently _public > String getSmtpPort()_ should be _public int getSmtpPort()_: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (EMAIL-118) smtpPort setter and getter doesn't works with the same type in EmailClass
[ https://issues.apache.org/jira/browse/EMAIL-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492765#comment-13492765 ] Thomas Neidhart edited comment on EMAIL-118 at 11/7/12 10:29 PM: - Pushing to 2.0 as it would break compatibility. Looking at the code, it is not quite clear why the port is actually stored as a String. It is put into the Session object, which requires a String value, but it could also be converted for this purpose. Maybe it is done for convenience reasons, so the value returned from the Session object can be directly used, and also to handle null cases. This could also be achieved with an Integer object. The same btw applies also to the sslSmtpPort property. was (Author: tn): Pushing to 2.0 as it would break compatibility. Looking at the code, it is not quite clear why the port is actually stored as a String. It is put into the Session object, which requires a String value, but it could also be converted for this purpose. The same btw applies also to the sslSmtpPort property. > smtpPort setter and getter doesn't works with the same type in EmailClass > - > > Key: EMAIL-118 > URL: https://issues.apache.org/jira/browse/EMAIL-118 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Xavier Detant >Priority: Trivial > Labels: patch > Fix For: 2.0 > > Attachments: SmtpAsInt.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > The smtpPort in the Email class can be set as an int but is get as a String. > This is quite bad design, the getter and the setter should works with the > same type. As smtp ports is a number, the getter which is currently _public > String getSmtpPort()_ should be _public int getSmtpPort()_: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-442) HDFS FileSystem Provider
[ https://issues.apache.org/jira/browse/VFS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492865#comment-13492865 ] Dave Marion commented on VFS-442: - Gary, When I get a few minutes I'll check out the patch. Regarding the build directory, its an HDFS store that is created by the embedded HDFS test cluster. I'd have to look to see if that directory location is configurable. Can we just add this directory to the svn-ignore list? > HDFS FileSystem Provider > > > Key: VFS-442 > URL: https://issues.apache.org/jira/browse/VFS-442 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Dave Marion >Priority: Minor > Labels: accumulo, hdfs > Attachments: vfs-422-3.diff, VFS-442-1.patch, VFS-442-2.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-442) HDFS FileSystem Provider
[ https://issues.apache.org/jira/browse/VFS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492870#comment-13492870 ] Gary Gregory commented on VFS-442: -- Yes, we could/should add "build" to the SVN ignore list. But the test should still clean up after itself. It would also help if the directory name were more obvious like "test-hdfs" but like you mentioned, you'll see if the location can be configured. > HDFS FileSystem Provider > > > Key: VFS-442 > URL: https://issues.apache.org/jira/browse/VFS-442 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Dave Marion >Priority: Minor > Labels: accumulo, hdfs > Attachments: vfs-422-3.diff, VFS-442-1.patch, VFS-442-2.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-68) Donation/Proposal for Commons-Email 2.0
[ https://issues.apache.org/jira/browse/EMAIL-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492894#comment-13492894 ] Gary Gregory commented on EMAIL-68: --- Sounds good to me. > Donation/Proposal for Commons-Email 2.0 > --- > > Key: EMAIL-68 > URL: https://issues.apache.org/jira/browse/EMAIL-68 > Project: Commons Email > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Ramiro Pereira de Magalhães > Fix For: 2.0 > > Attachments: commons.email2.zip > > > This is a donation of code to the commons-email project. I hope it inspires > people to create a more flexible, extensible and maintainable API for sending > e-mail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492973#comment-13492973
]
Alexander Kleymenov commented on JCS-73:
Here:
. // get previously stored value
. def res = cache.getFromGroup(idx-1, group)
we retrieve value written to the cache on previous iteration.
The problem is: some values just written to the cache can't be retrieved. When
test detects this, it prints:
. ERROR: for 8204 in Thread-9
Sometimes after several 'get' retries these lost values become accessible. Test
notifies:
. ERROR FIXED for 521: [value:[a:1, b:2, c:3], aux:[1:a, 2:b, 3:c,
t:Thread-8]] Thread-11
While 'get' retries are not successful (values looks lost), test prints:
. ERROR STILL PERSISTS for 8204 in Thread-9
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-2.0.0
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCS-73) concurrent cache access causes values loss
[
https://issues.apache.org/jira/browse/JCS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492976#comment-13492976
]
Alexander Kleymenov commented on JCS-73:
As to differences:
IndexedDiskCacheConcurrentUnitTest covers put/get methods.
Failing scenario uses putInGroup/getFromGroup.
> concurrent cache access causes values loss
> --
>
> Key: JCS-73
> URL: https://issues.apache.org/jira/browse/JCS-73
> Project: Commons JCS
> Issue Type: Bug
> Components: Indexed Disk Cache
>Affects Versions: jcs-1.3
>Reporter: Alexander Kleymenov
>Assignee: Thomas Vandahl
> Fix For: jcs-2.0.0
>
> Attachments: patch.txt, repro.zip
>
>
> The following groovy code demonstrates the problem: several threads write to
> the cache and try to read previously written values. Sometimes just written
> values can't be retrieved. In this case, subsequent tries can get the value,
> but not always.
> {code}
> cache = org.apache.jcs.JCS.getInstance("cache")
> group = "group"
> worker = {
> def name = Thread.currentThread().name
> 1.times { idx ->
> if (idx) {
> // get previously stored value
> def res = cache.getFromGroup(idx-1, group)
> if (!res) {
> // null value got inspite of the fact it was placed in cache!
> println "ERROR: for ${idx} in " + name
> // try to get the value again:
> def n = 5
> while (n-- > 0) {
> res = cache.getFromGroup(idx-1, group)
> if (res) {
> // the value finally appeared in cache
> println "ERROR FIXED for ${idx}: ${res} " + name
> break
> }
> println "ERROR STILL PERSISTS for ${idx} in " + name
> Thread.sleep(1000)
> }
> }
> }
> // put value in the cache
> cache.putInGroup(idx, group, [value:[a:1, b:2, c:3], aux:[1:'a',
> 2:'b', 3:'c', t:name]])
> if (!(idx % 1)) {
> println name+" "+idx
> }
> }
> }
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> Thread.start worker
> {code}
> Cache configuration:
> {code}
> jcs.default=CACHE
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=-1
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=10
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=10
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsRemote=false
> jcs.default.elementattributes.IsLateral=false
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsEternal=true
> jcs.auxiliary.CACHE=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
> jcs.auxiliary.CACHE.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
> jcs.auxiliary.CACHE.attributes.DiskPath=./cache
> jcs.auxiliary.CACHE.attributes.MaxPurgatorySize=-1
> jcs.auxiliary.CACHE.attributes.MaxKeySize=-1
> jcs.auxiliary.CACHE.attributes.MaxRecycleBinSize=500
> jcs.auxiliary.CACHE.attributes.ShutdownSpoolTimeLimit=60
> jcs.auxiliary.CACHE.attributes.OptimizeAtRemoveCount=3
> jcs.auxiliary.CACHE.attributes.OptimizeOnShutdown=true
> jcs.auxiliary.CACHE.attributes.EventQueueType=SINGLE
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IMAGING-98) Any hints on release date?
Ove Stoerholt created IMAGING-98: Summary: Any hints on release date? Key: IMAGING-98 URL: https://issues.apache.org/jira/browse/IMAGING-98 Project: Commons Imaging Issue Type: Question Reporter: Ove Stoerholt Priority: Trivial -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
