May 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0

by Paul Nardone (JIRA)

Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0 -------------------------------------------------------------------------------- Key: ISPN-663 URL: https://jira.jboss.org/browse/ISPN-663 Project: Infinispan Issue Type: Bug Components: Eviction, Loaders and Stores Affects Versions: 4.1.0.Final Environment: Win32 JRE 1.6.0_21 Reporter: Paul Nardone Assignee: Manik Surtani Attachments: InfinispanPassivationTest.java Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL. The degredation in performance is so signficant to make it impossible to use The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity. The attached test inserts 1000 values into two caches Both caches use a JdbmCacheStore and LRU PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10 PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000 4.1.0.FINAL PASSIVATIONLRU10 Time Taken : 51704 PASSIVATIONLRU1000 Time Taken : 4484 4.0.0.FINAL PASSIVATIONLRU10 Time Taken : 281 PASSIVATIONLRU1000 Time Taken : 141 4.2.0.ALPHA2 PASSIVATIONLRU10 Time Taken : 51047 PASSIVATIONLRU1000 Time Taken : 5156 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

5
36
0 / 0

[JBoss JIRA] Created: (ISPN-869) Enable automatic keyspace creation with cassandra 0.7

by Tristan Tarrant (JIRA)

Enable automatic keyspace creation with cassandra 0.7 ------------------------------------------------------ Key: ISPN-869 URL: https://issues.jboss.org/browse/ISPN-869 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 5.0.0.Final Cassandra 0.7 allows creation of keyspaces and columnfamilies at runtime. We should add a boolean flag (false by default) to automatically create the Infinispan keyspaces and columnfamilies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1144) Replicated caches should have state transfer enabled by default

by Galder Zamarreño (JIRA)

Replicated caches should have state transfer enabled by default --------------------------------------------------------------- Key: ISPN-1144 URL: https://issues.jboss.org/browse/ISPN-1144 Project: Infinispan Issue Type: Enhancement Components: State transfer Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.FINAL +1 on enabling state transfer for replicated caches; without ST replicated caches don't make much sense. --- On 5/27/11 5:32 PM, Galder Zamarreño wrote: Hey, Re: http://community.jboss.org/message/607524#607524 This guy didn't have state transfer enabled which is the cause for his initial issues. It's clear that http://community.jboss.org/docs/DOC-13690 needs to have state transfer in its config, otherwise replication does not make much sense... I'm doing this just now The other more key thing is probably making state transfer enabled by default for replicated caches. I previously looked into it but did not look straight forward to do as my comment here says: https://github.com/galderz/infinispan/blob/master/core/src/main/java/org/... However, I think it might be worth looking into it again. Thoughts? -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache -- Bela Ban Lead JGroups / Clustering Team JBoss -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (ISPN-721) Change CacheStore.store() to return the previous value instead of void.

by Trustin Lee (JIRA)

Change CacheStore.store() to return the previous value instead of void. ----------------------------------------------------------------------- Key: ISPN-721 URL: https://jira.jboss.org/browse/ISPN-721 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 Cache.put(key, value) operation returns a previous value. However, CacheStore.store() does not return a previous value but void. To overcome the impedance mismatch, the current implementation calls CacheStore.load() to simply get the previous value. CacheStore.store() could be improved to reduce this unnecessary round trip. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-1140) TransientMortalCacheEntry has incorrect implementation of setValue()

by Steven Newson (JIRA)

TransientMortalCacheEntry has incorrect implementation of setValue() -------------------------------------------------------------------- Key: ISPN-1140 URL: https://issues.jboss.org/browse/ISPN-1140 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.CR3, 4.2.1.FINAL Reporter: Steven Newson Assignee: Manik Surtani The implementation of {{setValue()}} in {{TransientMortalCacheEntry}} is as follows {code:java} public Object setValue(Object value) { return cacheValue.maxIdle; } {code} This leads to problems in the {{DefaultDataContainer}} as the following {{put()}} code has no effect: {code:java} public void put(Object k, Object v, long lifespan, long maxIdle) { InternalCacheEntry e = entries.get(k); if (e != null) { e.setValue(v); InternalCacheEntry original = e; e = entryFactory.update(e, lifespan, maxIdle); // we have the same instance. So we need to reincarnate. if(original == e) { e.reincarnate(); } } else { // this is a brand-new entry e = entryFactory.createNewEntry(k, v, lifespan, maxIdle); } entries.put(k, e); } {code} The effect of this for me is that the following steps via Hibernate don't work: - Insert record into table via Hibernate - Reload record by its ID - Change non-ID field on the record - Update the record via Hibernate - Reload the record by its ID - Check that the value reloaded matches the updated value The 2nd level cache always returns the first inserted record rather than the updated one. Each Hibernate access is inside its own transaction. I fixed this locally by overriding the class in the classpath, replacing the {{setValue()}} method with the following implementation: {code:java} public Object setValue(Object value) { Object original = cacheValue.value; cacheValue.value = value; return original; } {code} Which also corresponds to the (misspelled :)) Javadoc: {noformat}Sets the value of the entry, returing the previous value{noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
14
0 / 0

[JBoss JIRA] Created: (ISPN-1145) Additional NPE at transaction rollback

by Vladimir Blagojevic (JIRA)

Additional NPE at transaction rollback --------------------------------------- Key: ISPN-1145 URL: https://issues.jboss.org/browse/ISPN-1145 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR3 Reporter: Vladimir Blagojevic Assignee: Mircea Markus Fix For: 5.0.0.CR4 Noticed a bunch of NPEs during test suite execution: 2011-05-31 12:51:36,555 WARN [jta] (Transaction Reaper Worker 0) ARJUNA16045: attempted rollback of < formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffc0a80203:c3a4:4de4c7d1:291, node_name=1, branch_uid=0:ffffc0a80203:c3a4:4de4c7d1:292, eis_name=unknown eis name > (TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=< formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffc0a80203:c3a4:4de4c7d1:291, node_name=1, branch_uid=0:ffffc0a80203:c3a4:4de4c7d1:292, eis_name=unknown eis name >} LocalTransaction{remoteLockedNodes=[NodeA-39281], isMarkedForRollback=false, transaction=TransactionImple < ac, BasicAction: 0:ffffc0a80203:c3a4:4de4c7d1:291 status: ActionStatus.ABORTING >} org.infinispan.transaction.xa.LocalXaTransaction@f2c1c042}) failed with exception code - java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.infinispan.transaction.TransactionTable.failureCompletingTransaction(TransactionTable.java:176) at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:158) at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:135) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2869) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2848) at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1613) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) 2011-05-31 12:51:36,556 WARN [arjuna] (Transaction Reaper Worker 0) ARJUNA12091: Top-level abort of action 0:ffffc0a80203:c3a4:4de4c7d1:291 received TwoPhaseOutcome.FINISH_ERROR from com.arjuna.ats.arjuna.coordinator.AbstractRecord -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-1004) Lifecycle manager for plugin module is invoked twice per cache initialization on cacheStarting

by Sanne Grinovero (JIRA)

Lifecycle manager for plugin module is invoked twice per cache initialization on cacheStarting ---------------------------------------------------------------------------------------------- Key: ISPN-1004 URL: https://issues.jboss.org/browse/ISPN-1004 Project: Infinispan Issue Type: Bug Components: Core API, Querying Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 5.0.0.BETA1 In the search module the org.infinispan.query.impl.LifecycleManager is registered via the infinispan-module.properties, but the method {code}org.infinispan.query.impl.LifecycleManager.cacheStarting(ComponentRegistry, Configuration, String){code} Is invoked twice for each cache initialization. The implementation needs to register an interceptor, and some objects in the componentregistry. The tricky part is that some of these components are overwritten, some are not, leading to an inconsistent initialization (Query was made useless). I'm working around this in Query to register my needed components only if they're not already, but this is inconsistent as well as I might need to reconfigure it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
11
0 / 0

[JBoss JIRA] Created: (ISPN-1133) Core developer maven profile

by Galder Zamarreño (JIRA)

Core developer maven profile ---------------------------- Key: ISPN-1133 URL: https://issues.jboss.org/browse/ISPN-1133 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Optional Fix For: 5.0.0.CR4 It'd be nice to have a 'core-dev' profile in Maven that: - Skips the enforcer plugin - Skips generation of source jars This would speed up builds in either continous build or our local envs. Any more suggestions? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (ISPN-1079) Allow users to specify a build directory

by Dan Berindei (JIRA)

Allow users to specify a build directory ---------------------------------------- Key: ISPN-1079 URL: https://issues.jboss.org/browse/ISPN-1079 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.0.0.BETA2, 4.2.1.FINAL, 4.2.2.BETA1 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Optional Fix For: 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL If a user wants to speed up the build by compiling to a ramdisk, he should be able to set the build directory in ~/.m2/settings.xml, something like this: <settings> <profiles> <profile> <properties> <buildDirectory>/tmp/privatebuild/${project.basedir}/${project.version}</buildDirectory> </properties> </profile> </profiles> </settings> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-1143) Make Apache Avro dependency optional

by Galder Zamarreño (JIRA)

Make Apache Avro dependency optional ------------------------------------ Key: ISPN-1143 URL: https://issues.jboss.org/browse/ISPN-1143 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR4 The Hot Rod client only needs it if you're gonna configure the apache avro marshaller, so should be optional or provided. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2011