[JBoss JIRA] (ISPN-7104) Cache remove fails to return value in invalidation mode with cache store
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7104?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-7104:
-------------------------------------
Assignee: William Burns
> Cache remove fails to return value in invalidation mode with cache store
> ------------------------------------------------------------------------
>
> Key: ISPN-7104
> URL: https://issues.jboss.org/browse/ISPN-7104
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.4.Final
> Reporter: Vladimir Dzhuvinov
> Assignee: William Burns
> Priority: Critical
> Attachments: RemoveInInvalidationModeTest.java
>
>
> The cache `remove` method occasionally fails to return the removed value, and returns `null`.
> Observed in two node setup in invalidation mode, with a configured cache store (Redis).
> Tests reveal that about 40% of the times the method returns `null`, the remaining 60% the removed value is correctly returned.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 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 the TCK. The TCK should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients. The java client test suite covers all versions of HotRod protocol and the TCK should include tests for all these versions (not necessarily in separate groups). It should also include things that are not directly related to Hot Rod protocol such as tests related to failover, state transfer.
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 *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.
> 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 the TCK. The TCK should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients. The java client test suite covers all versions of HotRod protocol and the TCK should include tests for all these versions (not necessarily in separate groups). It should also include things that are not directly related to Hot Rod protocol such as tests related to failover, state transfer.
> 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, 7 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 commented on ISPN-7120:
-------------------------------------
Alan, I've included Dan's suggestion in the description.
> 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 the TCK. The TCK should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients. The java client test suite covers all versions of HotRod protocol and the TCK should include tests for all these versions (not necessarily in separate groups). It should also include things that are not directly related to Hot Rod protocol such as tests related to failover, state transfer.
> 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, 7 months
[JBoss JIRA] (ISPN-7125) Broken implementation (DistributedExecutionCompletionService) of CompletionService in Infinispan
by mohammad nadeem (JIRA)
mohammad nadeem created ISPN-7125:
-------------------------------------
Summary: Broken implementation (DistributedExecutionCompletionService) of CompletionService in Infinispan
Key: ISPN-7125
URL: https://issues.jboss.org/browse/ISPN-7125
Project: Infinispan
Issue Type: Bug
Reporter: mohammad nadeem
Infinispan has provided an implementation of `java.util.concurrent.CompletionService<V>` `org.infinispan.distexec.DistributedExecutionCompletionService<V>`, However this is broken, as the underlying blocking queue is non-distributed, the moment the node goes down (In which the queue resides), all the content of the nodes would be gone... further this queue is not shared with all the other nodes in the cluster..
And hence a truly distributed blocking queue implementation is required..
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ]
Alan Field commented on ISPN-7120:
----------------------------------
bq. Reducing the number of tests may not be so easy... remember that we
bq. need to test all versions of the protocol, not just the latest one.
bq. And we still need to test stuff that's not explicitly in the protocol,
bq. especially around state transfer/server crashes and around query
bq. (which the protocol says almost nothing about).
The above quote is from [~dan.berindei]. Should these also be included in the TCK?
> 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, 7 months
[JBoss JIRA] (ISPN-7124) Port JDBC Migrator
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7124?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-7124:
---------------------------------------
The migrator should allow adding custom classes (e.g. marshallers) so that conversion takes them into account.
> Port JDBC Migrator
> ------------------
>
> Key: ISPN-7124
> URL: https://issues.jboss.org/browse/ISPN-7124
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha4
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store. This could be an opportunity to create a generic store migrator, with a JDBC specific implementation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ISPN-7124) Port JDBC Migrator
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7124?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7124:
-------------------------------
Description: As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store. This could be an opportunity to create a generic store migrator, with a JDBC specific implementation. (was: As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store. )
> Port JDBC Migrator
> ------------------
>
> Key: ISPN-7124
> URL: https://issues.jboss.org/browse/ISPN-7124
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha4
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store. This could be an opportunity to create a generic store migrator, with a JDBC specific implementation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ISPN-7124) Port JDBC Migrator
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7124:
----------------------------------
Summary: Port JDBC Migrator
Key: ISPN-7124
URL: https://issues.jboss.org/browse/ISPN-7124
Project: Infinispan
Issue Type: Enhancement
Reporter: Ryan Emerson
Assignee: Ryan Emerson
As we are removing the JDBC mixed/binary stores it is necessary for us to include a migration tool to the string based store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months