[JBoss JIRA] (ISPN-3773) State transfer thread can stop even though there are pending transfer tasks
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3773?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3773:
--------------------------------
Labels: 630 nbst (was: nbst)
> State transfer thread can stop even though there are pending transfer tasks
> ---------------------------------------------------------------------------
>
> Key: ISPN-3773
> URL: https://issues.jboss.org/browse/ISPN-3773
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630, nbst
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Noticed in NonTxOriginatorBecomingPrimaryOwnerTest. The state transfer thread finished the last inbound transfer task, but just before stopping another task is started. The new task doesn't prevent the state transfer thread from stopping, and the node will never request those segments (thus blocking the rebalance from ending).
> {noformat}
> 15:28:31,033 TRACE (asyncTransportThread-1,NodeC:) [InboundTransferTask] Successfully requested segments [33, 6, 7, 8, 9, 11, 13, 50, 54, 20, 52, 22, 59, 25, 24, 27, 26, 29, 28, 31] of cache ___defaultcache from node NodeA-49040
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Adding transfer from NodeA-49040 for segments [32, 5, 6, 7, 8, 10, 12, 51, 49, 19, 21, 53, 23, 59, 25, 24, 27, 26, 28, 30]
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Starting transfer thread: false
> 15:28:31,264 DEBUG (remote-thread-1,NodeC:___defaultcache) [StateConsumerImpl] Finished adding inbound state transfer for segments [5, 6, 7, 8, 10, 12, 19, 21, 23, 25, 24, 27, 26, 28, 30, 32, 51, 49, 53, 59] of cache ___defaultcache
> 15:28:31,264 TRACE (remote-thread-1,NodeC:___defaultcache) [StateTransferLockImpl] Signalling transaction data received for topology 41
> 15:28:31,264 TRACE (asyncTransportThread-1,NodeC:) [StateConsumerImpl] Stopping state transfer thread
> {noformat}
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3767:
--------------------------------
Labels: 620 630 (was: 620)
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.4.Final
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3764:
--------------------------------
Labels: 620 630 testsuite_stability (was: 620 testsuite_stability)
> ISPN testsuite fails for RHEL6x64 && IBM JDK6
> ----------------------------------------------
>
> Key: ISPN-3764
> URL: https://issues.jboss.org/browse/ISPN-3764
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Final
> Environment: RHEL6x64 IBM6
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Priority: Critical
> Labels: 620, 630, testsuite_stability
> Fix For: 7.0.0.Alpha1
>
>
> Sometimes build is stucked and sometiemes it throws following exception when CORE module is running
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-DistWriteSkewTest) Exiting because DistWriteSkewTest has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-DistWriteSkewTest) See allocation stacktrace to find out where still-running cacheManager was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> java.lang.Throwable
> at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:160)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:125)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:177)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:162)
> at org.infinispan.test.MultipleCacheManagersTest.createCluster(MultipleCacheManagersTest.java:196)
> at org.infinispan.container.versioning.AbstractClusteredWriteSkewTest.createCacheManagers(AbstractClusteredWriteSkewTest.java:59)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79)
> at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> Add link to jenkins job
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3745:
--------------------------------
Labels: 620 630 (was: 620)
> Forwarded Prepare/Commit executed after transaction finished
> ------------------------------------------------------------
>
> Key: ISPN-3745
> URL: https://issues.jboss.org/browse/ISPN-3745
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630
> Fix For: 7.0.0.Alpha1
>
>
> Replicated TX cache, nodes A, B, C
> 0. A and B have topology 2, C already got topology 3
> 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
> 2. C forwards prepare to B with topology 3
> 3. A sends commit with topology 2 to B and C, both commit and respond
> 4. again, C forwards prepare to B with topology 3
> 5. A and B get updated topology id
> 6. A executes another transaction on the same entry
> 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again
> Result: on B we have inconsistent state
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3756) Unnecessary wall clock call for immortal entries
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3756?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3756:
--------------------------------
Labels: 630 (was: )
> Unnecessary wall clock call for immortal entries
> ------------------------------------------------
>
> Key: ISPN-3756
> URL: https://issues.jboss.org/browse/ISPN-3756
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> When updating immortal entries Infinispan calls up the wall clock time unnecessarily.
> {code}
> if (e != null) {
> e.setValue(v);
> InternalCacheEntry original = e;
> e = entryFactory.update(e, metadata);
> // we have the same instance. So we need to reincarnate.
> if (original == e) {
> --> e.reincarnate(timeService.wallClockTime());
> }
> } else {
> // this is a brand-new entry
> e = entryFactory.create(k, v, metadata);
> }
> {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
10 years, 11 months
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3738:
--------------------------------
Labels: 620 630 (was: 620)
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3731?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3731:
--------------------------------
Labels: 620 630 (was: 620)
> Multicast messages can be replayed to new node
> ----------------------------------------------
>
> Key: ISPN-3731
> URL: https://issues.jboss.org/browse/ISPN-3731
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Messages that target all current members are sent as multicast messages.
> However, these retransmissions can be replayed on new nodes that have just joined the cluster.
> This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them.
> The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId.
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3740) AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3740?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3740:
--------------------------------
Labels: 630 (was: )
> AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer
> ------------------------------------------------------------------------------------
>
> Key: ISPN-3740
> URL: https://issues.jboss.org/browse/ISPN-3740
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Labels: 630
> Fix For: 7.0.0.Alpha1
>
>
> The number of tests that use {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} and actually require state transfer to be disabled is insignificant: after commenting out the line that disables ST, I got 0 failures.
> The Infinispan default is to have state transfer enabled, so developers naturally assume that state transfer is enabled all the time. It would be much clearer if {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} used the same defaults.
--
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
10 years, 11 months
[JBoss JIRA] (ISPN-3737) L1 requestor registered after value read
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3737:
--------------------------------
Labels: 620 630 (was: 620)
> L1 requestor registered after value read
> ----------------------------------------
>
> Key: ISPN-3737
> URL: https://issues.jboss.org/browse/ISPN-3737
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent.
> Consider this interleaving of operations (G=get request from other node, C=commit)
> R: read value -> old value
> C: update old -> new
> C: notify requestors for key
> R: add requestor for key
--
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
10 years, 11 months