[JBoss JIRA] (ISPN-7114) Consistency checker
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-7114?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-7114:
--------------------------------
IspnPerfTest and RadarGun could use this after a run, to check if consistency is provided between cluster nodes. I'm thinking of a method in AdvancedCache that returns the number of inconsistent keys in a cluster. Perhaps it should return the keys directly (in a set)?
Also, the (or an additional) method might return actual keys and values, for a reconciliation strategy to perform repair. Alternatively, as [~NadirX] mentioned, this could be done by shipping user code to the nodes to do repair...
Can you propose some API and we'll discuss it on this JIRA?
> Consistency checker
> -------------------
>
> Key: ISPN-7114
> URL: https://issues.jboss.org/browse/ISPN-7114
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
>
> We should implement a consistency checker that can either be run on demand via management (e.g. JMX) or triggered by a merge or a topology change caused by abrupt leavers. It should perform per-segment analysis of each key/value pair between primary and backup. The design should incorporate pluggable repair strategies (e.g. latest wins, primary wins, discard, degrade segment, custom)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-7120:
--------------------------------
Description:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined *server-side* configuration. In order to make it easier to share the same server-side configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML server configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
was:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
> Refactor Java Hot Rod Client Test Suite
> ---------------------------------------
>
> Key: ISPN-7120
> URL: https://issues.jboss.org/browse/ISPN-7120
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Martin Gencur
>
> The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
> This task will involve a number of steps:
> 1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
> 2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
> 3) Each test should have a predefined *server-side* configuration. In order to make it easier to share the same server-side configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML server configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
> Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
> Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
> The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-7120:
--------------------------------
Description:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
was:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify tests for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
> Refactor Java Hot Rod Client Test Suite
> ---------------------------------------
>
> Key: ISPN-7120
> URL: https://issues.jboss.org/browse/ISPN-7120
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Martin Gencur
>
> The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
> This task will involve a number of steps:
> 1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
> 2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
> 3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
> Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
> Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
> The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-7120:
--------------------------------
Description:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify tests for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
was:
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify tests for the "TCK" first, have them in a spread sheet with suggested new package and explanation
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations withing the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
> Refactor Java Hot Rod Client Test Suite
> ---------------------------------------
>
> Key: ISPN-7120
> URL: https://issues.jboss.org/browse/ISPN-7120
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Martin Gencur
>
> The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
> This task will involve a number of steps:
> 1) Identify tests for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team.
> 2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose.
> 3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
> Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
> Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
> The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite
by Martin Gencur (JIRA)
Martin Gencur created ISPN-7120:
-----------------------------------
Summary: Refactor Java Hot Rod Client Test Suite
Key: ISPN-7120
URL: https://issues.jboss.org/browse/ISPN-7120
Project: Infinispan
Issue Type: Enhancement
Components: Remote Protocols
Reporter: Martin Gencur
The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test.
This task will involve a number of steps:
1) Identify tests for the "TCK" first, have them in a spread sheet with suggested new package and explanation
2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a package there. Possibly rename the tests to better reflect their purpose.
3) Each test should have a predefined configuration. In order to make it easier to share the same configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML configurations withing the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes.
Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache
Note: Marshalling is not part of tck. The tck should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients which is defined by the Hot Rod protocol.
The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-7119) Change cluster listener to use JGroups non OOB thread
by William Burns (JIRA)
William Burns created ISPN-7119:
-----------------------------------
Summary: Change cluster listener to use JGroups non OOB thread
Key: ISPN-7119
URL: https://issues.jboss.org/browse/ISPN-7119
Project: Infinispan
Issue Type: Feature Request
Reporter: William Burns
Assignee: William Burns
Cluster listeners could use non OOB thread from JGroups instead of distributed executor to enforce ordering. This would allow the primary owner to release the lock earlier by not having to wait for response from the cluster listener nodes.
This can lose a message though if the primary owner goes down after the originator got the response that the value was written but before the primary owner sent the message to the listeners. Also could have an issue that if state transfer occurs and the primary owner changes while in the same state you could get a new event from the new primary before the previous ones was received causing an ordering issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months