October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3079) xsite replication custom failurePolicy does now work with ASYNC strategy

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3079?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3079: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > xsite replication custom failurePolicy does now work with ASYNC strategy > ------------------------------------------------------------------------ > > Key: ISPN-3079 > URL: https://issues.jboss.org/browse/ISPN-3079 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 5.2.5.Final > Environment: ISPN 5.2.5.final > Reporter: dex chen > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > I configure xsite backupFailurePolicy="CUSTOM" and specified failurePolicyClass (see below xml configuration). > When the strategy is set to "ASYNC", the failurePolicyClass code is never got invoked!! > But, same code will will be invoked if the strategy is set to "SYNC". > ..... > <sites> > <backups> > <backup site="NYC" strategy="ASYNC" backupFailurePolicy="CUSTOM" failurePolicyClass="com.test.cluster.infinispan.CrossSiteReplicationFailurePolicy" timeout="12003"/> > </backups> > </sites> -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3086: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Infinite loop when creating more than two Distributed Cache nodes > ----------------------------------------------------------------- > > Key: ISPN-3086 > URL: https://issues.jboss.org/browse/ISPN-3086 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 5.3.0.Beta1 > Reporter: Balazs Zsoldos > Assignee: Galder Zamarreño > Priority: Critical > Labels: cache, distribution > Fix For: 6.0.0.Final > > Attachments: infinispan-three-nodes.zip > > > I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p... > I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop. > *The modified XML contains:* > <namedCache name="namedCache"> > <clustering mode="dist" /> > </namedCache> > *The modified java code contains:* > CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml"); > CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml"); > CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml"); > *Symptom:* > The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above. > Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core. > *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the benefit would come out between the two topologies with more nodes. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3076: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 5.2.5.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3202) Infinispan cachestores remove entries early when maxIdle used

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3202?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3202: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Infinispan cachestores remove entries early when maxIdle used > ------------------------------------------------------------- > > Key: ISPN-3202 > URL: https://issues.jboss.org/browse/ISPN-3202 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.6.Final > Environment: Linux: debian wheezy > uname -a: Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux > JBoss: 7.1.2.Final > Embedded cache using infinispan 5.2.6.Final jars included in WAR's WEB-INF/lib directory. > Reporter: Ralph Jennings > Assignee: Pedro Ruivo > Labels: cache-store, maxIdle, timeout > Fix For: 6.0.0.Final > > > When adding an entry to the cache (embedded), specifying maxIdle... The entry goes into the store, but the store removes the entry when maxIdle time elapses from creation (rather than from last access). > The cache correctly keeps the entry in memory (unless evicted). > This leaves the cache and store out of sync. > I saw this same behavior with both stringKeyedJdbcStore and fileStore. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3184) The DELTA_WRITE flag should force a remote get during state transfer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3184?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3184: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > The DELTA_WRITE flag should force a remote get during state transfer > -------------------------------------------------------------------- > > Key: ISPN-3184 > URL: https://issues.jboss.org/browse/ISPN-3184 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3177) "Read past EOF" in case of using async fileStore with "infinispan" directory_provider

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3177?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3177: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > "Read past EOF" in case of using async fileStore with "infinispan" directory_provider > ------------------------------------------------------------------------------------- > > Key: ISPN-3177 > URL: https://issues.jboss.org/browse/ISPN-3177 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory, Querying > Affects Versions: 5.2.4.Final > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Fix For: 6.0.0.Final > > Attachments: config.xml > > > The cache configuration is attached (config.xml). > While trying to run performance tests on the cache configured in the provided XML, i.e. performing parallel puts/gets with many threads (local mode), the following exception is thrown: > Please note that exception is thrown on Put. I've changed the tests so that only one thread is run, but anyway this issue appears. > If I comment the loader's part, then the test passes. > > {code} > org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager query > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230) > at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102) > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414) > at org.hibernate.search.spi.SearchFactoryBuilder.buildIncrementalSearchFactory(SearchFactoryBuilder.java:169) > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:149) > at org.hibernate.search.impl.MutableSearchFactory.addClasses(MutableSearchFactory.java:194) > at org.infinispan.query.backend.QueryInterceptor.enableClassesIncrementally(QueryInterceptor.java:225) > at org.infinispan.query.backend.QueryInterceptor.updateKnownTypesIfNeeded(QueryInterceptor.java:250) > at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:426) > at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:128) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) > at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:84) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) > at org.infi^Cnispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1162) > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:760) > at org.infinispan.CacheImpl.put(CacheImpl.java:754) > at org.infinispan.CacheImpl.put(CacheImpl.java:748) > at org.infinispan.CacheSupport.put(CacheSupport.java:53) > at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:244) > at org.radargun.cachewrappers.InfinispanExplicitLockingWrapper.put(InfinispanExplicitLockingWrapper.java:72) > at org.radargun.cachewrappers.InfinispanQueryWrapper.put(InfinispanQueryWrapper.java:72) > at org.radargun.stressors.StressTestStressor$FixedSetPerThreadOperationLogic.init(StressTestStressor.java:313) > at org.radargun.stressors.StressTestStressor$Stressor.run(StressTestStressor.java:541) > Caused by: org.hibernate.search.SearchException: Could not initialize index > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162) > at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103) > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104) > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227) > ... 33 more > Caused by: java.io.IOException: Read past EOF > at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77) > at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41) > at org.apache.lucene.store.DataInput.readInt(DataInput.java:86) > at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272) > at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182) > at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168) > at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157) > ... 36 more > {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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3160) RemoteCacheManager javadocs list wrong default pool size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3160?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3160: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > RemoteCacheManager javadocs list wrong default pool size > -------------------------------------------------------- > > Key: ISPN-3160 > URL: https://issues.jboss.org/browse/ISPN-3160 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.1.8.Final > Reporter: Dennis Reed > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 6.0.0.Final > > > RemoteCacheManager javadocs list the default pool size as 10: > "infinispan.client.hotrod.default_executor_factory.pool_size, default = 10." > However, the default is actually 99: > org/infinispan/client/hotrodimpl/ConfigurationProperties.java: return props.getIntProperty(DEFAULT_EXECUTOR_FACTORY_POOL_SIZE, 99); -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3119) Cleanup the scripts we ship with the distribution

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3119?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3119: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Cleanup the scripts we ship with the distribution > -------------------------------------------------- > > Key: ISPN-3119 > URL: https://issues.jboss.org/browse/ISPN-3119 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > Make sure that all the scripts we ship as part of the distribution are correct. Also update the [release process| https://docspace.corp.redhat.com/docs/DOC-28594] with exact stept to test the scripts we ship, e.g. > {quote} > 1. memcached server > $ ./startServer.sh -r memcached > # from a different console test the client > $ ./memcache.py > - ./bin/startServer.sh -r memcached > 2. Pi approximation demo. Open 3 consoles on the same machine > $ ./runPiApproximationDemo.sh > $ ./runPiApproximationDemo.sh > $ ./runPiApproximationDemo.sh -t master > {quote} > -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3209) Server operation to suppress state transfer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3209?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3209: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Server operation to suppress state transfer > ------------------------------------------- > > Key: ISPN-3209 > URL: https://issues.jboss.org/browse/ISPN-3209 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.Final > > > This issue is to provide a Server operation for the functionality implemented in ISPN-3140 -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3204) Implement Last-Modified header returned by REST endpoint correctly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3204?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3204: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Implement Last-Modified header returned by REST endpoint correctly > ------------------------------------------------------------------ > > Key: ISPN-3204 > URL: https://issues.jboss.org/browse/ISPN-3204 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 6.0.0.Final > > > As described in ISPN-3153, the Last-Modified HTTP header does not always return correct date/time of the last modification. > The goal of this JIRA is to fix this behaviour. > Explanation of the bug: > "Since immortal entries never die, we don't track creation time for them. We don't wanna be doing that either cos it takes valuable space that's might only be relevant for REST. In fact, we don't have anything that maps directly to last-modified per se. For transient entries, we track when the entry was last used (read or write) and for mortal entries, we track the creation time, which is not necessarily last modified time. Last-modified returns the expected value only when timeToLiveSeconds has been set and we're tracking creation time (mortal entry)." -- 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

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013