April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3725) Recovery does not work with versioning

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3725?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3725: ----------------------------------- Affects Version/s: 6.0.2.Final > Recovery does not work with versioning > -------------------------------------- > > Key: ISPN-3725 > URL: https://issues.jboss.org/browse/ISPN-3725 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.0.CR1, 6.0.2.Final > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Fix For: 7.2.0.CR1, 7.2.0.Final > > > It seems like this combination is unexpected (see stacktrace below) > However, writeSkewCheck requires SIMPLE versioning scheme. > {code} > java.lang.ClassCastException: org.infinispan.container.versioning.SimpleClusteredVersion cannot be cast to org.infinispan.container.versioning.NumericVersion > at org.infinispan.transaction.xa.TransactionFactory$TxFactoryEnum$4.newGlobalTransaction(TransactionFactory.java:140) > at org.infinispan.transaction.xa.TransactionFactory.newGlobalTransaction(TransactionFactory.java:245) > at org.infinispan.transaction.TransactionTable.getOrCreateLocalTransaction(TransactionTable.java:319) > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:277) > at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:240) > at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:186) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:197) > at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:132) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) > at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296) > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869) > at org.infinispan.CacheImpl.put(CacheImpl.java:861) > at org.infinispan.CacheImpl.put(CacheImpl.java:1349) > at org.infinispan.CacheImpl.put(CacheImpl.java:206) > at org.radargun.cachewrappers.InfinispanBasicOperations.put(InfinispanBasicOperations.java:25) > at org.radargun.cachewrappers.Infinispan51BasicOperations.put(Infinispan51BasicOperations.java:31) > at org.radargun.cachewrappers.Infinispan52BasicOperations.put(Infinispan52BasicOperations.java:16) > at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:184) > at org.radargun.stages.ClusterValidationStage.tryToPut(ClusterValidationStage.java:137) > at org.radargun.stages.ClusterValidationStage.checkReplicationSeveralTimes(ClusterValidationStage.java:149) > at org.radargun.stages.ClusterValidationStage.executeOnSlave(ClusterValidationStage.java:58) > at org.radargun.Slave$2.run(Slave.java:103) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5019: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.CR1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5019: ----------------------------------- Fix Version/s: 7.2.0.Final > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.CR1, 7.2.0.Final > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5019: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1195565|https://bugzilla.redhat.com/show_bug.cgi?id=1195565] from ASSIGNED to POST > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.CR1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5368?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5368: ------------------------------------ Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/3377, https://github.com/infinispan/infinispan/pull/3382 (was: https://github.com/infinispan/infinispan/pull/3377) > Out of order events produced when using the MassIndexer with async backend > -------------------------------------------------------------------------- > > Key: ISPN-5368 > URL: https://issues.jboss.org/browse/ISPN-5368 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2, 7.1.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.2.0.CR1, 7.2.0.Final > > > When using async indexing backend on DIST caches with shared index (InfinispanIndexManager), the MassIndexer fails to re-index all the entries, if it is run from a node that is not > the indexing master. > Normally the operation sequence of the MassIndexer in the above configuration, for a two node cluster is: > * Purge the index > * Send index job to node A and to node B > * Flush > Given the backend is async, all index commands are sent to the master RPC-wise asynchronously, and so a reorder can occur and produce like: > * Send index job to node A > * Purge > * Send index job to node B > * Flush > Causing previously re-indexed entries to be wiped -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5368?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reopened ISPN-5368: ------------------------------------- Missed a check > Out of order events produced when using the MassIndexer with async backend > -------------------------------------------------------------------------- > > Key: ISPN-5368 > URL: https://issues.jboss.org/browse/ISPN-5368 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2, 7.1.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.2.0.CR1, 7.2.0.Final > > > When using async indexing backend on DIST caches with shared index (InfinispanIndexManager), the MassIndexer fails to re-index all the entries, if it is run from a node that is not > the indexing master. > Normally the operation sequence of the MassIndexer in the above configuration, for a two node cluster is: > * Purge the index > * Send index job to node A and to node B > * Flush > Given the backend is async, all index commands are sent to the master RPC-wise asynchronously, and so a reorder can occur and produce like: > * Send index job to node A > * Purge > * Send index job to node B > * Flush > Causing previously re-indexed entries to be wiped -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5265) Optimize Getall operations over Hot Rod

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5265?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5265: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1198556|https://bugzilla.redhat.com/show_bug.cgi?id=1198556] from ASSIGNED to POST > Optimize Getall operations over Hot Rod > --------------------------------------- > > Key: ISPN-5265 > URL: https://issues.jboss.org/browse/ISPN-5265 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > > - GetAll operation: to ensure that there’s a way to batch get multiple objects together. > - Improve performance for large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5266) Optimize PutAll operations (Hot Rod)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5266?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5266: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1198556|https://bugzilla.redhat.com/show_bug.cgi?id=1198556] from ASSIGNED to POST > Optimize PutAll operations (Hot Rod) > ------------------------------------ > > Key: ISPN-5266 > URL: https://issues.jboss.org/browse/ISPN-5266 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.CR1, 7.2.0.Final > > > - PutAll: to ensure that users can load massive amount of data into the grid quickly over Hot Rod. > - Performance improvement over large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5264) Optimize PutAll operations (library mode)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5264?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5264: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1198556|https://bugzilla.redhat.com/show_bug.cgi?id=1198556] from ASSIGNED to POST > Optimize PutAll operations (library mode) > ----------------------------------------- > > Key: ISPN-5264 > URL: https://issues.jboss.org/browse/ISPN-5264 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.CR1, 7.2.0.Final > > > - PutAll: to ensure that users can load massive amount of data into the grid quickly in Library mode > - Performance improvement over large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2183: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1198556|https://bugzilla.redhat.com/show_bug.cgi?id=1198556] from ASSIGNED to POST > Add the ability to fetch a set of keys at once (getAll) > ------------------------------------------------------- > > Key: ISPN-2183 > URL: https://issues.jboss.org/browse/ISPN-2183 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > > When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement: > 1. all the keys can be fetched from remote nodes in parallel > 2. keys that map to the same node can be grouped and fetched in the same RPC request > > Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 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 April 2015