[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3767:
--------------------------------
Fix Version/s: 6.1.0.Final
Priority: Major (was: Minor)
> 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
> Fix For: 6.1.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, 6 months
[JBoss JIRA] (ISPN-3773) State transfer thread can stop even though there are pending transfer tasks
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3773?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3773:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2258
> 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: nbst
> Fix For: 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, 6 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3745:
-----------------------------------
Topology 18 does not contain the joiner, 19 contains it.
> 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
>
> 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, 6 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on ISPN-3767:
--------------------------------------
Hi Adrian,
as you stated that 3 or more nodes was fixing the issue on the DistributedMassIndexingTest, I've tried to set up a 4 nodes cluster to run my import + mass index scenario. However, if the query works when I import with indexing, it keeps failing if I use the MassIndexer. I've published this new test case on github:
https://github.com/rpelisse/ISPN-3767
> 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
> Priority: Minor
>
> 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, 6 months
[JBoss JIRA] (ISPN-3784) Exiting because has NOT shut down all the cache managers it has started
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3784?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3784:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2257
> Exiting because has NOT shut down all the cache managers it has started
> -----------------------------------------------------------------------
>
> Key: ISPN-3784
> URL: https://issues.jboss.org/browse/ISPN-3784
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Final
> Environment: All environmets
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: testsuite_stability
>
> When following tests are running from infinispan testsuite
> RemoteStoreTest
> RemoteStoreRawValuesTest
> Adaptor52xCustomLoaderTest
> Adaptor52xCustomStoreTest
> JdbcStringTest
> FileStoreTest
> MixedStoreWithManagedConnectionTest
> JdbcMixedStore2Test
> Following exception is thrown
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-MixedStoreWithManagedConnectionTest) Exiting because *Test has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-MixedStoreWithManagedConnectionTest) See allocation stacktrace to find out where still-running cacheManager (org.infinispan.manager.DefaultCacheManager@51696e47@Address:null) 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.createCacheManager(TestCacheManagerFactory.java:185)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:170)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:174)
> at org.infinispan.marshall.TestObjectStreamMarshaller.<init>(TestObjectStreamMarshaller.java:34)
> at org.infinispan.persistence.BaseStoreTest.setUp(BaseStoreTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 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:744)
> All of tests are superclasses of BaseStoreTest. Tests are passing well but when after all tests checkManagersClosed() from TestCacheManagerFactory is called there are some RUNNING cache managers and VM is stopped.
> Add link to jenkins job for RHEL and Windows
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> 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, 6 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3745:
------------------------------------
Is topologyId = 18 the id of the topology that contains the joiner, or the topology before? If it's the new topology, and the command was initially invoked remotely with topology 17, then the command was forwarded, otherwise it was likely retransmitted by JGroups.
I'm inclined to think it's caused by JGroups retransmitting the message to the joiner and the originator not waiting for the response, too.
> 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
>
> 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, 6 months
[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3422:
------------------------------------
These are the changes I made:
* Replace the ignorePreviousValue flag with a ValueMatchingPolicy enum.
* Set the matching policy to MATCH_EXPECTED_OR_NEW when retrying a
putIfAbsent(k, value).
* replace(k, expected, newValue) and remove(k, expected) will also be
retried with MATCH_EXPECTED_OR_NEW.
* Check the primary owner's response and update the status of the command.
Only successful commands should be retried if the topology changes.
Regular put(k, value) still won't be atomic, because we don't keep the previous value around. Same as regular put(k, value), replace(k, newValue) and remove(k) won't be atomic.
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
> Key: ISPN-3422
> URL: https://issues.jboss.org/browse/ISPN-3422
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, nbst
> Fix For: 6.1.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {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, 6 months
[JBoss JIRA] (ISPN-3786) REST server is treating timeToLiveSeconds=0 inconsistently
by Jakub Markos (JIRA)
Jakub Markos created ISPN-3786:
----------------------------------
Summary: REST server is treating timeToLiveSeconds=0 inconsistently
Key: ISPN-3786
URL: https://issues.jboss.org/browse/ISPN-3786
Project: Infinispan
Issue Type: Bug
Components: Remote protocols
Reporter: Jakub Markos
Assignee: Galder Zamarreño
The REST server currently handles 0 values for timeToLiveSeconds and maxIdleTimeSeconds like this:
||timeToLiveSeconds||maxIdleTimeSeconds||used lifespan||used maxIdle||
|0|0|default from config|default from config|
|nothing or >0|0|whatever came or -1|default from config|
|0|nothing or >0|literally 0(*entry expires immediately*)|whatever came or -1|
After discussion with Galder, the last line doesn't really make sense, and the better way would be to use default for timeToLive as well.
--
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, 6 months