[JBoss JIRA] (ISPN-7121) CacheEntryExpired event doesn't work with no auto commit in a clustered cache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7121?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-7121:
-------------------------------------
Exception encountered that prevents removeExpired from working properly.
{code}
11:42:35,984 WARN (testng-ReplNoAutoCommitExpiryTest) [ClusterExpirationManager] ISPN000026: Caught exception purging data container!
java.lang.IllegalArgumentException: Cannot create a transactional context without a valid Transaction instance.
at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:68)
at org.infinispan.cache.impl.CacheImpl.getInvocationContext(CacheImpl.java:763)
at org.infinispan.cache.impl.CacheImpl.getInvocationContextWithImplicitTransaction(CacheImpl.java:755)
at org.infinispan.cache.impl.CacheImpl.removeExpired(CacheImpl.java:544)
at org.infinispan.expiration.impl.ClusterExpirationManager.removeExpired(ClusterExpirationManager.java:111)
at org.infinispan.expiration.impl.ClusterExpirationManager.lambda$handleLifespanExpireEntry$0(ClusterExpirationManager.java:97)
at org.infinispan.expiration.impl.ClusterExpirationManager.handleLifespanExpireEntry(ClusterExpirationManager.java:103)
at org.infinispan.expiration.impl.ClusterExpirationManager.processExpiration(ClusterExpirationManager.java:67)
{code}
> CacheEntryExpired event doesn't work with no auto commit in a clustered cache
> -----------------------------------------------------------------------------
>
> Key: ISPN-7121
> URL: https://issues.jboss.org/browse/ISPN-7121
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
>
> Expired events are not generated for clustered caches which has transactions without auto commit. Local caches work fine though.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 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)
9 years, 5 months