March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7614) Disabling a store doesn't stop it

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7614: ---------------------------------- Summary: Disabling a store doesn't stop it Key: ISPN-7614 URL: https://issues.jboss.org/browse/ISPN-7614 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Final When disabling a store via {{PersistenceManager.disableStore(...)}}, the store is removed from the list of loaders/writers, but its {{stop()}} method is not called, so buffers may not be flushed. {{AsyncCacheWriter}} will also leak the {{AsyncStoreCoordinator}} thread if {{stop()}} is not called, and this thread leak is visible when running {{ClassLoaderManagerDisablingTest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7614) Disabling a store doesn't stop it

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7614?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7614: ------------------------------- Status: Open (was: New) > Disabling a store doesn't stop it > --------------------------------- > > Key: ISPN-7614 > URL: https://issues.jboss.org/browse/ISPN-7614 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Final > > > When disabling a store via {{PersistenceManager.disableStore(...)}}, the store is removed from the list of loaders/writers, but its {{stop()}} method is not called, so buffers may not be flushed. > {{AsyncCacheWriter}} will also leak the {{AsyncStoreCoordinator}} thread if {{stop()}} is not called, and this thread leak is visible when running {{ClassLoaderManagerDisablingTest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7613) Enable write-skew for optimistic + repeatable-read transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7613?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7613: ------------------------------ Description: 2 changes in this task: * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew was: 2 changes on this task: * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew > Enable write-skew for optimistic + repeatable-read transactions > --------------------------------------------------------------- > > Key: ISPN-7613 > URL: https://issues.jboss.org/browse/ISPN-7613 > Project: Infinispan > Issue Type: Sub-task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > 2 changes in this task: > * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew > * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7613) Enable write-skew for optimistic + repeatable-read transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7613?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7613: ------------------------------ Status: Open (was: New) > Enable write-skew for optimistic + repeatable-read transactions > --------------------------------------------------------------- > > Key: ISPN-7613 > URL: https://issues.jboss.org/browse/ISPN-7613 > Project: Infinispan > Issue Type: Sub-task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > 2 changes on this task: > * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew > * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7613) Enable write-skew for optimistic + repeatable-read transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7613?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7613: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4971 > Enable write-skew for optimistic + repeatable-read transactions > --------------------------------------------------------------- > > Key: ISPN-7613 > URL: https://issues.jboss.org/browse/ISPN-7613 > Project: Infinispan > Issue Type: Sub-task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > 2 changes on this task: > * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew > * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7613) Enable write-skew for optimistic + repeatable-read transactions

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-7613: --------------------------------- Summary: Enable write-skew for optimistic + repeatable-read transactions Key: ISPN-7613 URL: https://issues.jboss.org/browse/ISPN-7613 Project: Infinispan Issue Type: Sub-task Reporter: Pedro Ruivo Assignee: Pedro Ruivo 2 changes on this task: * it is no longer possible to configure repeatable-read + optimistic transaction without write-skew * default configuration changed from read-committed + optimistic transaction to repeatable-read + optimistic transaction + write-skew -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7612) We should marshall all classes when using converter

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7612?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7612: -------------------------------- Status: Open (was: New) > We should marshall all classes when using converter > --------------------------------------------------- > > Key: ISPN-7612 > URL: https://issues.jboss.org/browse/ISPN-7612 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Final > > > The old store as binary used to not convert some classes to binary [1]. This never worked with MEMORY based eviction. There is no reason to not convert these now, which will make these types work with MEMORY based eviction. For example Lucene indexes store jgroups address. > [1] https://github.com/infinispan/infinispan/blob/abd4d744bdf2a8777295317bfc8... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7612) We should marshall all classes when using converter

by William Burns (JIRA)

William Burns created ISPN-7612: ----------------------------------- Summary: We should marshall all classes when using converter Key: ISPN-7612 URL: https://issues.jboss.org/browse/ISPN-7612 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.CR2 Reporter: William Burns Assignee: William Burns Fix For: 9.0.0.Final The old store as binary used to not convert some classes to binary [1]. This never worked with MEMORY based eviction. There is no reason to not convert these now, which will make these types work with MEMORY based eviction. For example Lucene indexes store jgroups address. [1] https://github.com/infinispan/infinispan/blob/abd4d744bdf2a8777295317bfc8... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ] Work on ISPN-7120 stopped by Anna Manukyan. ------------------------------------------- > 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 > Assignee: Anna Manukyan > > 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 (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ] Anna Manukyan commented on ISPN-7120: ------------------------------------- The first step of this jira is done. The document is created which contains all classes from hotrod-client testsuite and integration testsuite with their description, if it worth to add specific class to tck testsuite and the package suggestion. The document can be found here: https://docs.google.com/spreadsheets/d/1bZBBi5m4oLL4lBTZhdRbIC_EA0giQNDZW... and is ready for review. > 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 > Assignee: Anna Manukyan > > 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 (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017