[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2813:
-----------------------------------
Fix Version/s: 7.2.0.Final
> DummyTransaction do not commit is last resource transaction is read-only
> ------------------------------------------------------------------------
>
> Key: ISPN-2813
> URL: https://issues.jboss.org/browse/ISPN-2813
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.6.FINAL
> Reporter: Vitalii Tymchyshyn
> Assignee: Pedro Ruivo
> Priority: Minor
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Currently HEAD DummyTransaction.java has this code:
> ...
> for (XAResource res : resources) {
> try {
> int prepareStatus = res.prepare(xid);
> transaction.setPrepareStatus(prepareStatus);
> ...
> This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted.
> Also it has next code:
> ...
> if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) {
> log.debug("This is a read-only tx");
> } else {
> ... Do commit ...
> ...
> This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed.
> For me this results in locks held indefinitely and transaction leak.
> Correct would be to remember prepare status per-resource and act accordinly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-5274) Inconsistent data after transaction rollback (with success on originator)
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5274?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5274:
-----------------------------------
Fix Version/s: 7.2.0.CR1
7.2.0.Final
Affects Version/s: 7.1.1.Final
> Inconsistent data after transaction rollback (with success on originator)
> -------------------------------------------------------------------------
>
> Key: ISPN-5274
> URL: https://issues.jboss.org/browse/ISPN-5274
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.1.Final
> Reporter: Matej Čimbora
> Assignee: Dan Berindei
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Scenario
> Nodes edg-perf[10-13], partition handling on
> 1.Transaction is started on edg-perf10
> {code}
> 10:24:48,228 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-6) start called on tx GlobalTransaction:<edg-perf10-20667>:38910:local
> {code}
> 2. Value of key_000000000000065B is updated within the transaction
> {code}
> 10:24:48,405 TRACE [org.radargun.service.InfinispanOperations$Cache] (DefaultStressor-6) PUT cache=testCache key=key_000000000000065B value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ]
> {code}
> 3. Transaction is successfully prepared on edg-perf11 & edg-perf12
> {code}
> 10:24:48,559 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-6) Responses: [sender=edg-perf11-61837, received=true, suspected=false]
> [sender=edg-perf12-7305, received=true, suspected=false]
> {code}
> 4. Transaction commit is issued
> {code}
> 10:24:48,562 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-6) Committing transaction GlobalTransaction:<edg-perf10-20667>:38910:local
> {code}
> 5. Other participating nodes (edg-perf11 & edg-perf12) are suspected...
> {code}
> 10:24:52,705 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf11-61837 left during remote call, ignoring
> 10:24:52,716 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf12-7305 left during remote call, ignoring
> {code}
> ... as they received a new view (without edg-perf10) meanwhile.
> {code}
> 10:24:48,547 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf12-7305) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf12-7305|20] (3) [edg-perf12-7305, edg-perf11-61837, edg-perf13-25187], 2 subgroups: [edg-perf13-25187|8] (1) [edg-perf13-25187], [edg-perf13-25187|19] (1) [edg-perf13-25187]
> {code}
> Still, the transaction is commited on edg-perf10 & updated entry is stored locally
> {code}
> 10:24:52,894 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Trying to commit. Key=key_000000000000065B. Operation Flag=null, L1 invalidation=false
> 10:24:52,896 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Committing key=key_000000000000065B. It is a L1 invalidation or a normal put and no tracking is enabled!
> 10:24:52,908 TRACE [org.infinispan.container.DefaultDataContainer] (DefaultStressor-6) Creating new ICE for writing. Existing=ImmortalCacheEntry{key=key_000000000000065B, value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}, metadata=EmbeddedMetadata{version=null}, new value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ]
> {code}
> 6. Other nodes rollback the transaction
> {code}
> 10:24:50,376 DEBUG [org.infinispan.transaction.TransactionTable] (transport-thread-10) Rolling back transaction GlobalTransaction:<edg-perf10-20667>:38910:remote because originator edg-perf10-20667 left the cluster
> {code}
> 7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value
> {code}
> 10:25:09,614 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf10-20667) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf10-20667|22] (3) [edg-perf10-20667, edg-perf11-61837, edg-perf13-25187], 4 subgroups: [edg-perf10-20667|15] (2) [edg-perf10-20667, edg-perf11-61837], [edg-perf10-20667|19] (3) [edg-perf10-20667, edg-perf12-7305, edg-perf11-61837], [edg-perf10-20667|18] (1) [edg-perf10-20667], [edg-perf10-20667|21] (2) [edg-perf10-20667, edg-perf13-25187]
> {code}
> 8. get operation returns outdated value
> {code}
> 10:26:21,020 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-6) Response(s) to ClusteredGetCommand{key=key_000000000000065B, flags=null} is {edg-perf12-7305=SuccessfulResponse{responseValue=ImmortalCacheValue {value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}} }
> {code}
> From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-5274) Inconsistent data after transaction rollback (with success on originator)
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5274?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5274:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Inconsistent data after transaction rollback (with success on originator)
> -------------------------------------------------------------------------
>
> Key: ISPN-5274
> URL: https://issues.jboss.org/browse/ISPN-5274
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.1.Final
> Reporter: Matej Čimbora
> Assignee: Dan Berindei
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Scenario
> Nodes edg-perf[10-13], partition handling on
> 1.Transaction is started on edg-perf10
> {code}
> 10:24:48,228 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-6) start called on tx GlobalTransaction:<edg-perf10-20667>:38910:local
> {code}
> 2. Value of key_000000000000065B is updated within the transaction
> {code}
> 10:24:48,405 TRACE [org.radargun.service.InfinispanOperations$Cache] (DefaultStressor-6) PUT cache=testCache key=key_000000000000065B value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ]
> {code}
> 3. Transaction is successfully prepared on edg-perf11 & edg-perf12
> {code}
> 10:24:48,559 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-6) Responses: [sender=edg-perf11-61837, received=true, suspected=false]
> [sender=edg-perf12-7305, received=true, suspected=false]
> {code}
> 4. Transaction commit is issued
> {code}
> 10:24:48,562 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-6) Committing transaction GlobalTransaction:<edg-perf10-20667>:38910:local
> {code}
> 5. Other participating nodes (edg-perf11 & edg-perf12) are suspected...
> {code}
> 10:24:52,705 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf11-61837 left during remote call, ignoring
> 10:24:52,716 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf12-7305 left during remote call, ignoring
> {code}
> ... as they received a new view (without edg-perf10) meanwhile.
> {code}
> 10:24:48,547 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf12-7305) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf12-7305|20] (3) [edg-perf12-7305, edg-perf11-61837, edg-perf13-25187], 2 subgroups: [edg-perf13-25187|8] (1) [edg-perf13-25187], [edg-perf13-25187|19] (1) [edg-perf13-25187]
> {code}
> Still, the transaction is commited on edg-perf10 & updated entry is stored locally
> {code}
> 10:24:52,894 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Trying to commit. Key=key_000000000000065B. Operation Flag=null, L1 invalidation=false
> 10:24:52,896 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Committing key=key_000000000000065B. It is a L1 invalidation or a normal put and no tracking is enabled!
> 10:24:52,908 TRACE [org.infinispan.container.DefaultDataContainer] (DefaultStressor-6) Creating new ICE for writing. Existing=ImmortalCacheEntry{key=key_000000000000065B, value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}, metadata=EmbeddedMetadata{version=null}, new value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ]
> {code}
> 6. Other nodes rollback the transaction
> {code}
> 10:24:50,376 DEBUG [org.infinispan.transaction.TransactionTable] (transport-thread-10) Rolling back transaction GlobalTransaction:<edg-perf10-20667>:38910:remote because originator edg-perf10-20667 left the cluster
> {code}
> 7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value
> {code}
> 10:25:09,614 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf10-20667) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf10-20667|22] (3) [edg-perf10-20667, edg-perf11-61837, edg-perf13-25187], 4 subgroups: [edg-perf10-20667|15] (2) [edg-perf10-20667, edg-perf11-61837], [edg-perf10-20667|19] (3) [edg-perf10-20667, edg-perf12-7305, edg-perf11-61837], [edg-perf10-20667|18] (1) [edg-perf10-20667], [edg-perf10-20667|21] (2) [edg-perf10-20667, edg-perf13-25187]
> {code}
> 8. get operation returns outdated value
> {code}
> 10:26:21,020 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-6) Response(s) to ClusteredGetCommand{key=key_000000000000065B, flags=null} is {edg-perf12-7305=SuccessfulResponse{responseValue=ImmortalCacheValue {value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}} }
> {code}
> From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4546:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.2.0.Final
Resolution: Done
> Possible stale lock when the primary owner leaves during rebalance
> ------------------------------------------------------------------
>
> Key: ISPN-4546
> URL: https://issues.jboss.org/browse/ISPN-4546
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha5, 7.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null
> B sends prepareCommand(tx1, put(k, v)) to C, D
> D adds backup locks and replies
> C acquires lock, ready to send reply to B
> A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E]
> A, C and E install topology T+1, B and D do not
> E requests and receives tx data from C, including tx1
> C leaves
> B sees a SuspectException, sends rollbackCommand(tx1) to C, D
> D removes tx1
> C has left, but is ignored
> B reports to the user that the tx has been rolled back
> B and D install topology T+1 (optional)
> A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E]
> A, B, D, E all install topology T+2
> E requests and receives state from D, but it does not remove tx1
> A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null
> E now has a stale backup lock on k
> It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E.
> A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4546:
-----------------------------------
Affects Version/s: 7.1.1.Final
> Possible stale lock when the primary owner leaves during rebalance
> ------------------------------------------------------------------
>
> Key: ISPN-4546
> URL: https://issues.jboss.org/browse/ISPN-4546
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha5, 7.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null
> B sends prepareCommand(tx1, put(k, v)) to C, D
> D adds backup locks and replies
> C acquires lock, ready to send reply to B
> A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E]
> A, C and E install topology T+1, B and D do not
> E requests and receives tx data from C, including tx1
> C leaves
> B sees a SuspectException, sends rollbackCommand(tx1) to C, D
> D removes tx1
> C has left, but is ignored
> B reports to the user that the tx has been rolled back
> B and D install topology T+1 (optional)
> A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E]
> A, B, D, E all install topology T+2
> E requests and receives state from D, but it does not remove tx1
> A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null
> E now has a stale backup lock on k
> It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E.
> A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-4751) Hibernate search, infinispan and Amazon S3 - IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4751?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4751:
---------------------------------------
Hi George,
the internals of Lucene have changed dramatically between version 3 and 4, that would be a couple of weeks work.
If you have some hours to help out, I'm pretty sure that they would be better spent helping with the work on the faceting features of Search 5 ?
Hardy just sent a preview pull request at https://github.com/hibernate/hibernate-search/pull/819
we're still reviewing it from a design and integration point of view, but having your feedback from actual real world data and tests would be awesome, as it would take us quite some more time to run such tests, and when we do it's usually quite synthetic data since we're not having a real performance requirement.
> Hibernate search, infinispan and Amazon S3 - IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4751
> URL: https://issues.jboss.org/browse/ISPN-4751
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Lance Ess
> Assignee: Vojtech Juranek
>
> I'm trying to use hibernate-search to host a Lucene index on Amazon S3 but I'm getting the following exception:
> {code}
> Exception in thread "LuceneIndexesData-CloudCacheStore-0" java.lang.IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
> at org.infinispan.loaders.bucket.Bucket.setBucketId(Bucket.java:84)
> at org.infinispan.loaders.cloud.CloudCacheStore.readFromBlob(CloudCacheStore.java:450)
> at org.infinispan.loaders.cloud.CloudCacheStore.scanBlobForExpiredEntries(CloudCacheStore.java:292)
> at org.infinispan.loaders.cloud.CloudCacheStore.purge(CloudCacheStore.java:284)
> at org.infinispan.loaders.cloud.CloudCacheStore.purgeInternal(CloudCacheStore.java:336)
> at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:111)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> The documentation for persisting Lucene indexes on Amazon-S3 is a little sparse but I think I'm on the right track. I'm trying to start infinispan embedded within my application so I've specified a path to the infinispan XML as follows in my hibernate.cfg.xml
> {code:xml}
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> <property name="hibernate.search.infinispan.configuration_resourcename">infinispan-amazons3.xml</property>
> <property name="hibernate.search.infinispan.chunk_size">300000000</property>
> {code}
> And my infinispan-amazons3.xml is:
> {code:xml}
> <infinispan>
> <default>
> <loaders>
> <cloudStore xmlns="urn:infinispan:config:cloud:5.3"
> cloudService="aws-s3"
> identity="user"
> password="password"
> bucketPrefix="bucket">
> </cloudStore>
> </loaders>
> </default>
> </infinispan>
> {code}
> I'm using the following versions (maven pom.xml)
> {code}
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-search</artifactId>
> <version>4.4.4.Final</version>
> </dependency>
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-search-infinispan</artifactId>
> <version>4.4.4.Final</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-cachestore-cloud</artifactId>
> <version>5.3.0.Final</version>
> </dependency>
> <dependency>
> <groupId>org.jclouds.provider</groupId>
> <artifactId>aws-s3</artifactId>
> <version>1.4.1</version>
> </dependency>
> {code}
> I initially thought this was related to ISPN-1909 but my version is after the fix for that issue (5.1.3.CR1, 5.1.3.FINAL)
> FYI here's my maven dependency tree (grepped for infinispan)
> {code}
> $ mvn dependency:tree | grep infinispan
> [INFO] +- org.hibernate:hibernate-search-infinispan:jar:4.4.4.Final:compile
> [INFO] | \- org.infinispan:infinispan-lucene-directory:jar:5.3.0.Final:compile
> [INFO] +- org.infinispan:infinispan-cachestore-cloud:jar:5.3.0.Final:compile
> [INFO] | \- org.infinispan:infinispan-core:jar:5.3.0.Final:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5368?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5368:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master. Thanks [~gustavonalle]!
> 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, 11 months
[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:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.2.0.Final
Resolution: Done
> 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