April 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1944) SuspectedException blocks cluster formation

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1944: ------------------------------------ Summary: SuspectedException blocks cluster formation Key: ISPN-1944 URL: https://issues.jboss.org/browse/ISPN-1944 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.2.FINAL Reporter: Michal Linhard Assignee: Manik Surtani This happened in JDG 6.0.0.ER4. The cluster with first two nodes formed alright and when node3 was joining, it got SuspectedException for some reason, and then prepare in node01 failed with timeout (10min). logs here: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
30
0 / 0

[JBoss JIRA] (ISPN-1838) State transfer takes more than 10 minutes with only 10K entries.

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1838: ------------------------------------ Summary: State transfer takes more than 10 minutes with only 10K entries. Key: ISPN-1838 URL: https://issues.jboss.org/browse/ISPN-1838 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.1.1.CR1 Reporter: Michal Linhard Assignee: Manik Surtani This could be categorized as a performance problem. It happened in resilience test run: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j... originally to verify ISPN-1826 It was run with infinispan special build from Galder's branch (https://github.com/galderz/infinispan/tree/t_1826_5) http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-build-... test starts 4 nodes, kills node2, starts node2 and sees what happens trace logging on server side was on. there were two runs 200 clients, 10K entries http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j... 20 clients, 1K entries http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j... in run 24 everyting looks nice: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/j... in run 23 the state transfer takes forever (more than 10 min) these important views are installed on coordinator (node03): {code} 2012-02-02 05:11:00,560 TRACE [BaseStateTransferManagerImpl] (transport-thread-1) Received new cache view: testCache CacheView{viewId=6, members=[edg-perf04-45788, edg-perf03-36944, edg-perf02-51026, edg-perf01-47003]} 2012-02-02 05:15:13,591 TRACE [BaseStateTransferManagerImpl] (transport-thread-9) Received new cache view: testCache CacheView{viewId=7, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003]} 2012-02-02 05:18:17,219 TRACE [BaseStateTransferManagerImpl] (transport-thread-1) Received new cache view: testCache CacheView{viewId=8, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]} 2012-02-02 05:28:17,511 TRACE [BaseStateTransferManagerImpl] (transport-thread-22) Received new cache view: testCache CacheView{viewId=10, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]} {code} viewId=8 is the one that takes 10 min to prepare and after that the prepare fails: {code} 2012-02-02 05:28:17,219 ERROR [CacheViewsManagerImpl] (CacheViewInstaller-9,edg-perf03-36944) ISPN000172: Failed to prepare view CacheView{viewId=8, members=[edg-perf04-45788, edg-perf03-36944, edg-perf01-47003, edg-perf02-21799]} for cache testCache, ro.. java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) at java.util.concurrent.FutureTask.get(FutureTask.java:91) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:319) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:250) at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:877) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) {code} viewId=10 is a retry and that succeeds quite quickly but the test is already ending about that time. It might be worth looking at the tracelogs since they're already there... 10K entries and 200 clients isn't such a big load ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

8
61
0 / 0

[JBoss JIRA] (ISPN-1995) Uneven request balancing after node restore

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-1995: ------------------------------------- Summary: Uneven request balancing after node restore Key: ISPN-1995 URL: https://issues.jboss.org/browse/ISPN-1995 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.4.CR1 Reporter: Tristan Tarrant Assignee: Galder Zamarreño After a node crashes and rejoins the cluster, it does not receive client load at the same level as the other nodes. This issue does not affect data integrity and distribution in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

4
54
0 / 0

[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context

by Manik Surtani (JIRA)

ManagedConnectionPool doesn't work in a transactional context ------------------------------------------------------------- Key: ISPN-586 URL: https://jira.jboss.org/browse/ISPN-586 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 >From the reporter: "Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain. This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix." This possibly has to do with the AbstractCacheStore doing the following in prepare(): " public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } " and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores. -- 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, 7 months

8
25
0 / 0

[JBoss JIRA] (ISPN-1610) Timeouts waiting for StateTransferLock

by Tristan Tarrant (Created) (JIRA)

Timeouts waiting for StateTransferLock -------------------------------------- Key: ISPN-1610 URL: https://issues.jboss.org/browse/ISPN-1610 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.0.CR1 Reporter: Tristan Tarrant Assignee: Dan Berindei In a four node performance tests we're seeing these exceptions during cluster startup: org.infinispan.distribution.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view X The timeout is set to the default 1min. It's quite suspicious that a state transfer takes that long ( > 1min) since caches are empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
29
0 / 0

[JBoss JIRA] (ISPN-1799) We should avoid using exceptions for flow control when acquiring state transfer lock

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1799: ---------------------------------- Summary: We should avoid using exceptions for flow control when acquiring state transfer lock Key: ISPN-1799 URL: https://issues.jboss.org/browse/ISPN-1799 Project: Infinispan Issue Type: Task Components: State transfer Affects Versions: 5.1.0.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL We currently use `StateTransferInProgressException` as a marker that a write command failed to acquire the state transfer lock and it should be retried. With ISPN-1704 I added another exception, StateTransferLockReacquisitionException, to signal that a write command failed to re-acquire the state transfer lock after it had already acquired it. These exceptions often appear in the logs and confuse users (see ISPN-1610), so it would be best to use special return values. We may also need a flag in the InvocationContext for StateTransferLockReacquisitionException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

7
28
0 / 0

[JBoss JIRA] (ISPN-1876) clustered query is not executed on the right cache

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1876: -------------------------------------- Summary: clustered query is not executed on the right cache Key: ISPN-1876 URL: https://issues.jboss.org/browse/ISPN-1876 Project: Infinispan Issue Type: Bug Components: Querying, RPC Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Sanne Grinovero when using clustered query, command is not executed on the right cache. when debuging, in CommandAwareRpcDispatcher::executeCommand() cmd = ClusteredQuery{cache="the-good-cache-name"} cmd.cache = "the-bad-cache-name" cmd.cacheName = "the-good-cache-name" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1969) Nullpointer Exception when NON_TRANSACTIONAL caching

by Roland Csupor (JIRA)

Roland Csupor created ISPN-1969: ----------------------------------- Summary: Nullpointer Exception when NON_TRANSACTIONAL caching Key: ISPN-1969 URL: https://issues.jboss.org/browse/ISPN-1969 Project: Infinispan Issue Type: Bug Components: Cache Server, Configuration, Spring integration Affects Versions: 5.1.3.FINAL Reporter: Roland Csupor Assignee: Manik Surtani Priority: Critical I am using infinispan mixed. Non transactional spring cache and transactional L1 cache. Spring cache region config looks like this: {noformat} <namedCache name="springCache"> <transaction transactionMode="NON_TRANSACTIONAL"/> <eviction maxEntries="100" strategy="NONE" /> <expiration lifespan="3600000" wakeUpInterval="600000" /> <invocationBatching enabled="false" /> <storeAsBinary enabled="true" storeKeysAsBinary="true" storeValuesAsBinary="true"/> </namedCache> {noformat} My global configuration is: {noformat} <global> <evictionScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory"> <properties> <property name="threadNamePrefix" value="EvictionThread" /> </properties> </evictionScheduledExecutor> <globalJmxStatistics allowDuplicateDomains="true" enabled="true" jmxDomain="org.infinispan" cacheManagerName="SampleCacheManager" /> </global> {noformat} And default is: {noformat} <default> <locking isolationLevel="READ_COMMITTED" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="5000" useLockStriping="false" /> <transaction transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" syncRollbackPhase="false" syncCommitPhase="false" useEagerLocking="false" eagerLockSingleNode="false" lockingMode="OPTIMISTIC" autoCommit="false" transactionMode="TRANSACTIONAL" /> <jmxStatistics enabled="true" /> <invocationBatching enabled="true" /> </default> {noformat} Actually I get NullPointerException: {noformat} java.lang.NullPointerException: null at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:72) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:95) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:60) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.CacheImpl.get(CacheImpl.java:272) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.CacheImpl.get(CacheImpl.java:264) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] at org.infinispan.spring.provider.SpringCache.get(SpringCache.java:74) ~[infinispan-spring-5.1.3.FINAL.jar:5.1.3.FINAL] at org.springframework.cache.interceptor.CacheAspectSupport.inspectCacheables(CacheAspectSupport.java:310) ~[spring-context-3.1.1.RELEASE.jar:3.1.1.RELEASE] at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:198) ~[spring-context-3.1.1.RELEASE.jar:3.1.1.RELEASE] at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:66) ~[spring-context-3.1.1.RELEASE.jar:3.1.1.RELEASE] at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) ~[spring-aop-3.1.1.RELEASE.jar:3.1.1.RELEASE] at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) ~[spring-aop-3.1.1.RELEASE.jar:3.1.1.RELEASE] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
18
0 / 0

[JBoss JIRA] (ISPN-1964) Preloading from store lead to doubled keys in full distributed environment

by Marc Pellmann (JIRA)

Marc Pellmann created ISPN-1964: ----------------------------------- Summary: Preloading from store lead to doubled keys in full distributed environment Key: ISPN-1964 URL: https://issues.jboss.org/browse/ISPN-1964 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.3.FINAL Reporter: Marc Pellmann Assignee: Manik Surtani Priority: Critical Distributed data from shared data store with one owner. On preload there will be 1) double keys 2) not full balanced see for full description: https://community.jboss.org/message/726337#726337 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
8
0 / 0

[JBoss JIRA] (ISPN-1588) IndexOutOfBoundsException while using clustered query

by Mathieu Lachance (Created) (JIRA)

IndexOutOfBoundsException while using clustered query ----------------------------------------------------- Key: ISPN-1588 URL: https://issues.jboss.org/browse/ISPN-1588 Project: Infinispan Issue Type: Bug Components: Querying, RPC Affects Versions: 5.1.0.BETA5 Reporter: Mathieu Lachance Assignee: Sanne Grinovero when using clustered query with dist sync mode i'm running into index out of bound exception. java.lang.IndexOutOfBoundsException: Index: 100, Size: 100 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at org.infinispan.query.clustered.DistributedIterator.current(DistributedIterator.java:138) at org.infinispan.query.clustered.DistributedIterator.next(DistributedIterator.java:114) at org.infinispan.query.clustered.ClusteredCacheQueryImpl.list(ClusteredCacheQueryImpl.java:136) at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:239) at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:200) at com.XXX.ClientCache.getClientsByServerId(ClientCache.java:168) at com.XXX.getClientsByServerId(ClientManager.java:157) at com.XXX$PingClient.run(PlayerBll.java:890) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) i do not have any reproductible step, but here's what i know : it only seems to happen under high contention ; when i'm running stress test. when running a stress test i might get query that return over than 100 results. tough i've also seen it happen on query that can only return few (4-6) results. i never saw the stack trace with different index and size different than 100 (it's always the exact same exception). i've also tried the lazy iterator to see if it would have a different behavior, but i get the same stack trace. is there anything i could look up in the source code to debug and maybe find the repro steps ? thanks, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2012