February 2017 - infinispan-issues

[JBoss JIRA] (ISPN-5657) Add missing embedded configuration elements to server schema

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5657?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5657: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Add missing embedded configuration elements to server schema > ------------------------------------------------------------ > > Key: ISPN-5657 > URL: https://issues.jboss.org/browse/ISPN-5657 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR2 > > > The embedded and server schema, while mostly compatible with each other, still differ in a number of aspects, e.g. store-as-binary, unsafe, etc. > The server should be able to parse these additional elements. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5672) Add support for proto3 version of the Protobuf definition language

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5672?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5672: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Add support for proto3 version of the Protobuf definition language > ------------------------------------------------------------------ > > Key: ISPN-5672 > URL: https://issues.jboss.org/browse/ISPN-5672 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5709) Support for running Infinispan as an Application in YARN

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5709?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5709: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Support for running Infinispan as an Application in YARN > -------------------------------------------------------- > > Key: ISPN-5709 > URL: https://issues.jboss.org/browse/ISPN-5709 > Project: Infinispan > Issue Type: Feature Request > Components: Hadoop Integration > Reporter: Gustavo Fernandes > Fix For: 9.0.0.CR2 > > > Hadoop 2.x allows custom "applications" to be managed by the resource scheduler framework. As an example, Apache Spark, Apache Tez, HBase and others can be bootstrapped and managed on top of Yarn. > Running on top of Yarn offers the following capabilities: > * Creating on demand (or long running) clusters with a simple command line, possibly targeting different versions and/or number of nodes > * Increase/Decrease the number of nodes as required > * Fine grained control of memory/CPU/disk/network utilized > * Submit arbitrary jobs targeting the application -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5728) Implement all the default methods in Java 8's Map interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5728?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5728: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Implement all the default methods in Java 8's Map interface > ----------------------------------------------------------- > > Key: ISPN-5728 > URL: https://issues.jboss.org/browse/ISPN-5728 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 8.0.0.Final > Reporter: Dan Berindei > Fix For: 9.0.0.CR2 > > > Java 8 added many new methods to the {{Map}} interface. Some of them were already present in {{ConcurrentMap}}, but others are new: {{getOrDefault()}}, {{forEach()}}, {{replaceAll()}}, {{computeIfAbsent()}}, {{computeIfPresent()}}, {{compute()}}, {{merge()}}. > We should try to write Infinispan-specific implementations wherever that would improve correctness and/or performance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5712) Remove buckets from JdbcBinaryStore

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5712?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5712: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Remove buckets from JdbcBinaryStore > ----------------------------------- > > Key: ISPN-5712 > URL: https://issues.jboss.org/browse/ISPN-5712 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 7.2.4.Final, 8.0.0.CR1 > Reporter: Dan Berindei > Fix For: 9.0.0.CR2 > > > Unlike a file system, relational databases can easily deal with millions of entries in the same table, so there's no reason to group entries into buckets. > Some databases may not be able to index on a binary column, in which case the serialized key will need encoding (e.g. BASE64), but grouping entries by hash code should not be necessary. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5642) Reduce contention in the RPC timeout handling

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5642?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5642: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Reduce contention in the RPC timeout handling > --------------------------------------------- > > Key: ISPN-5642 > URL: https://issues.jboss.org/browse/ISPN-5642 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Labels: help_wanted > Fix For: 9.0.0.CR2 > > > Most of the RPC timeout tasks are cancelled way before their timeout expires. This means the scheduler spends a lot of time reordering the elements of its DelayQueue. > It should be possible to store the tasks with a long timeout (e.g. 1s) in a queue and only move them to the scheduler's priority queue when they have less than 1s to expiration (e.g. by a worker thread that runs every 0.5s) > Storing all the tasks in a single queue may be impractical because the worker thread would have more and work to do as load increases and the RPCs take longer to finish, so a [hashed timing wheel|http://www.cse.wustl.edu/~cdgill/courses/cs6874/TimingWheels.ppt] may be needed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5757) Clustered statistics for transactions

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5757?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5757: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Clustered statistics for transactions > ------------------------------------- > > Key: ISPN-5757 > URL: https://issues.jboss.org/browse/ISPN-5757 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Transactions > Affects Versions: 8.0.1.Final > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.CR2 > > > We want to return clustered statistics for transactions commits, rollbacks and prepares. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5617) Clearly define which cachestores are shared and which are non-shared

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5617?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5617: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Clearly define which cachestores are shared and which are non-shared > -------------------------------------------------------------------- > > Key: ISPN-5617 > URL: https://issues.jboss.org/browse/ISPN-5617 > Project: Infinispan > Issue Type: Task > Reporter: Tristan Tarrant > Fix For: 9.0.0.CR2 > > > Cache stores should explicitly declare if they work in shared or non-shared mode, so that unsupported configurations cannot be started. > See http://lists.jboss.org/pipermail/infinispan-dev/2015-July/016076.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5654: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > Make DeadlockDetectingLockManager aware of single-node locking > -------------------------------------------------------------- > > Key: ISPN-5654 > URL: https://issues.jboss.org/browse/ISPN-5654 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Fix For: 9.0.0.CR2 > > > {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner. > In particular, {{isSameKeyDeadlock}} can probably be removed altogether. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6040: ---------------------------------- Fix Version/s: 9.0.0.CR2 (was: 9.0.0.CR1) > FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6040 > URL: https://issues.jboss.org/browse/ISPN-6040 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.CR2 > > > Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove. > In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove. > {noformat} > java.lang.AssertionError: expected:<null> but was:<v0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194) > at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2017