[JBoss JIRA] (ISPN-3491) PessDistCacheOperationsTest is failing randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3491?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3491:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2060
> PessDistCacheOperationsTest is failing randomly
> -----------------------------------------------
>
> Key: ISPN-3491
> URL: https://issues.jboss.org/browse/ISPN-3491
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 6.0.0.Alpha4
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Beta1
>
>
> I found that the ResetOfflineStatusTest is not closing all the JGroups channel after the test because it is using a DelegatingTransport. The delegatingTransport.stop() is never invoked because it is not present in the metadata extracted when the code is compiled (i.e. the GCR cannot find any stopMethods)
> solution: I've created an abstract class in the core and extended in the test suite. the component metadata persister will persist the abstract class and register the start()/stop() methods.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3491) PessDistCacheOperationsTest is failing randomly
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3491:
---------------------------------
Summary: PessDistCacheOperationsTest is failing randomly
Key: ISPN-3491
URL: https://issues.jboss.org/browse/ISPN-3491
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication
Affects Versions: 6.0.0.Alpha4
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 6.0.0.Beta1
I found that the ResetOfflineStatusTest is not closing all the JGroups channel after the test because it is using a DelegatingTransport. The delegatingTransport.stop() is never invoked because it is not present in the metadata extracted when the code is compiled (i.e. the GCR cannot find any stopMethods)
solution: I've created an abstract class in the core and extended in the test suite. the component metadata persister will persist the abstract class and register the start()/stop() methods.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3431) Lost version info during state transfer causes overwtite of newer data that joining node has read from store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3431?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3431:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1006998
> Lost version info during state transfer causes overwtite of newer data that joining node has read from store
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3431
> URL: https://issues.jboss.org/browse/ISPN-3431
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3
> Environment: uname -s ; cat /etc/redhat-release ; java -version
> Linux
> Red Hat Enterprise Linux Server release 5.9 (Tikanga)
> java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> Reporter: Nikolay Martynov
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 6.0.0.CR1
>
>
> When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
> Scenario:
> {noformat}
> 1. Start node1, node2, node3
> 2. Put {A=>A1} from node1
> 3. Put {B=>B1} from node2
> 4. Put {C=>C1} from node3
> 5. Gracefully shutdown node1 saving the data
> 6. Gracefully shutdown node2 saving the data
> 7. Put {C=>C2} from node3
> 8. Gracefully shutdown node3 saving the data
> 9. Start node1 loading the data
> 10. Start node2 loading the data
> 11. Start node3 loading the data
> {noformat}
> Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
> {noformat}
> org.infinispan.interceptors.CallInterceptor
> Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
> {noformat}
> During state transfer older value C1 is received with version information being null:
> {noformat}
> org.infinispan.statetransfer.StateTransferInterceptor
> handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
> {noformat}
> As a result newer value is replaced with older:
> {noformat}
> org.infinispan.interceptors.EntryWrappingInterceptor
> About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
> {noformat}
> As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> This is just a very simplistic example configuration file. For more information, please see
> http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
> -->
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
> <transport>
> <properties>
> <property name="configurationFile" value="jgroups.xml" />
> </properties>
> </transport>
> </global>
> <namedCache name="routing_table">
> <clustering mode="REPL">
> <stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
> <sync replTimeout="1000"/>
> <!--async useReplQueue="true" replQueueMaxElements="100" /-->
> </clustering>
> <loaders passivation="false" shared="false" preload="true">
> <singleFileStore
> location="target/routing_table${infinispan.store_name:not_specified}/">
> </singleFileStore>
> </loaders>
> <versioning enabled="true" versioningScheme="SIMPLE"/>
> <transaction
> transactionMode="TRANSACTIONAL"
> autoCommit="true"
> transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
> lockingMode="OPTIMISTIC"
> />
> <locking
> writeSkewCheck="true"
> isolationLevel="REPEATABLE_READ"/>
> </namedCache>
> </infinispan>
> {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
12 years, 7 months
[JBoss JIRA] (ISPN-3431) Lost version info during state transfer causes overwtite of newer data that joining node has read from store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3431?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3431:
-----------------------------------------------
Randy <randythomas34(a)gmail.com> made a comment on [bug 1006998|https://bugzilla.redhat.com/show_bug.cgi?id=1006998]
The problem starts with three remote nodes running in replicated mode. Each node is using a local cache store from which data is loaded upon startup.
1 Start node1, node2, node3
2 Put A⇒A1 from node1
3 Put B⇒B1 from node2
4 Put C⇒C1 from node3
5 Gracefully shutdown node1 saving the data
6 Gracefully shutdown node2 saving the data
7 Put C⇒C2 from node3
8 Gracefully shutdown node3 saving the data
9 Start node1 loading the data
10 Start node2 loading the data
11 Start node3 loading the data
12 Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have: org.infinispan.interceptors.CallInterceptor Executing command: PutKeyValueCommandC, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadataSimpleClusteredVersion{topologyId=8, version=2}, successful=true, ignorePreviousValue=false.
13 During state transfer older value C1 is received with version information being null: org.infinispan.statetransfer.StateTransferInterceptor handleNonTxWriteCommand for command PutKeyValueCommandC, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadatanull, successful=true, ignorePreviousValue=false
14 As a result newer value is replaced with older: org.infinispan.interceptors.EntryWrappingInterceptor About to commit entry ClusteredRepeatableReadEntry(323f265b)C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadataSimpleClusteredVersion{topologyId=8, version=2}
Actual results
The old value for entry C replaces the newer value.
Expected results
The new value of C should be retained on node3 and overwrite the old value of C on nodes 1 and 2.
How to Reproduced with the Attached archive
Please find attached archive with the Maven project that contains code implementing the scenario and bundling all configuration files for Infinispan and JGroups.
To run the scenario:
1 Start node1: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Dinfinispan.store_name=A -jar infinispan-proto-5-1.0-SNAPSHOT.jar A
2 Start node2 in separate console: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Djgroups.tcp.port=7801 -Dinfinispan.store_name=B -jar infinispan-proto-5-1.0-SNAPSHOT.jar B
3 Start node3 in separate console: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Djgroups.tcp.port=7802 -Dinfinispan.store_name=C -jar infinispan-proto-5-1.0-SNAPSHOT.jar C
4 At this time all nodes will put their values to map and exit persisting data in standard Infinispan’s file store. Before node3 exists, it waits for node1 and node2 to leave and then changes its value C one again before persisting data and exiting.
5 Start node1: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Dinfinispan.store_name=A -jar infinispan-proto-5-1.0-SNAPSHOT.jar A
6 Start node2 in separate console: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Djgroups.tcp.port=7801 -Dinfinispan.store_name=B -jar infinispan-proto-5-1.0-SNAPSHOT.jar B
7 Start node3 in separate console: java -Djava.net.preferIPv4Stack=true -Dignore.bind.address=true -Djgroups.tcpping.initial_hosts=localhost[7800] -Djgroups.tcp.port=7802 -Dinfinispan.store_name=C -jar infinispan-proto-5-1.0-SNAPSHOT.jar C
8 At this time newer version of configuration written by node3 gets reset to older value and last configuration update is lost. This can be seen by “C ⇒ C1 ←--------- Should be C2” in console for node3 (well, as in other consoles too) (Delete file store content to re-run scenario again.)
> Lost version info during state transfer causes overwtite of newer data that joining node has read from store
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3431
> URL: https://issues.jboss.org/browse/ISPN-3431
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3
> Environment: uname -s ; cat /etc/redhat-release ; java -version
> Linux
> Red Hat Enterprise Linux Server release 5.9 (Tikanga)
> java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> Reporter: Nikolay Martynov
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 6.0.0.CR1
>
>
> When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
> Scenario:
> {noformat}
> 1. Start node1, node2, node3
> 2. Put {A=>A1} from node1
> 3. Put {B=>B1} from node2
> 4. Put {C=>C1} from node3
> 5. Gracefully shutdown node1 saving the data
> 6. Gracefully shutdown node2 saving the data
> 7. Put {C=>C2} from node3
> 8. Gracefully shutdown node3 saving the data
> 9. Start node1 loading the data
> 10. Start node2 loading the data
> 11. Start node3 loading the data
> {noformat}
> Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
> {noformat}
> org.infinispan.interceptors.CallInterceptor
> Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
> {noformat}
> During state transfer older value C1 is received with version information being null:
> {noformat}
> org.infinispan.statetransfer.StateTransferInterceptor
> handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
> {noformat}
> As a result newer value is replaced with older:
> {noformat}
> org.infinispan.interceptors.EntryWrappingInterceptor
> About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
> {noformat}
> As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> This is just a very simplistic example configuration file. For more information, please see
> http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
> -->
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
> <transport>
> <properties>
> <property name="configurationFile" value="jgroups.xml" />
> </properties>
> </transport>
> </global>
> <namedCache name="routing_table">
> <clustering mode="REPL">
> <stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
> <sync replTimeout="1000"/>
> <!--async useReplQueue="true" replQueueMaxElements="100" /-->
> </clustering>
> <loaders passivation="false" shared="false" preload="true">
> <singleFileStore
> location="target/routing_table${infinispan.store_name:not_specified}/">
> </singleFileStore>
> </loaders>
> <versioning enabled="true" versioningScheme="SIMPLE"/>
> <transaction
> transactionMode="TRANSACTIONAL"
> autoCommit="true"
> transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
> lockingMode="OPTIMISTIC"
> />
> <locking
> writeSkewCheck="true"
> isolationLevel="REPEATABLE_READ"/>
> </namedCache>
> </infinispan>
> {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
12 years, 7 months
[JBoss JIRA] (ISPN-3490) extend compatibility mode tests
by Mircea Markus (JIRA)
Mircea Markus created ISPN-3490:
-----------------------------------
Summary: extend compatibility mode tests
Key: ISPN-3490
URL: https://issues.jboss.org/browse/ISPN-3490
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Mircea Markus
- to cover map/reduce
- to cover embedded queries
- to cover listeners
- transaction
-.. pretty much all the existing functionality
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3488) Add test for remote queries on top of Infinispan Directory provider
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-3488?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-3488:
-------------------------------------
Hi Adrian,
I understood, thanks for the explanation.
So currently I'm working on testing the remote queries and adding tests to the existing ones. As soon as I'll perform a pull request, I'll place the link here.
Best regards,
Anna.
> Add test for remote queries on top of Infinispan Directory provider
> -------------------------------------------------------------------
>
> Key: ISPN-3488
> URL: https://issues.jboss.org/browse/ISPN-3488
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Fix For: 6.0.0.Beta1
>
> Attachments: HotRodQueryIspnDirectoryTest.java, HotRodQueryTest.java
>
>
> The Remote Queries don't work with Infinispan Directory as a directory_provider.
> The exception thrown is:
> {code}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.infinispan.query.remote.indexing.ProtobufValueWrapper
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:217)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.client.hotrod.query.HotRodQueryTest.testAttributeQuery(HotRodQueryTest.java:85)
> 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:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> You can find attached the test - org.infinispan.client.hotrod.query.HotRodQueryTest and org.infinispan.client.hotrod.query.HotRodQueryIspnDirectoryTest. The failing one is the HotRodQueryIspnDirectoryTest which is extended from the first one.
--
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
12 years, 7 months