April 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6421) Instantiation of cache based on template should not modify template

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6421?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6421: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Instantiation of cache based on template should not modify template > ------------------------------------------------------------------- > > Key: ISPN-6421 > URL: https://issues.jboss.org/browse/ISPN-6421 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.0.Final > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > In cache add, instiating a cache A based on template T should not modify T but should create a configuration A under configurations=CONFIGURATIONS with the "template" attribute set to false and the "configuration" attribute set to T and then a cache A with "configuration" A. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6420) Allow DSL based polymorphic queries (embedded only)

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6420?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6420: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Allow DSL based polymorphic queries (embedded only) > --------------------------------------------------- > > Key: ISPN-6420 > URL: https://issues.jboss.org/browse/ISPN-6420 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > A query should return subtypes of the queried entities, provided these types are known to the indexer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6418) Gather continuous query statistics

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6418?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6418: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Gather continuous query statistics > ---------------------------------- > > Key: ISPN-6418 > URL: https://issues.jboss.org/browse/ISPN-6418 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Compute statistics similar to the ones provided by org.hibernate.search.jmx.StatisticsInfoMBean -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6405) Persistence configuration with clustered cache can cause duplicate expiration messages

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6405?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6405: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Persistence configuration with clustered cache can cause duplicate expiration messages > -------------------------------------------------------------------------------------- > > Key: ISPN-6405 > URL: https://issues.jboss.org/browse/ISPN-6405 > Project: Infinispan > Issue Type: Bug > Components: Expiration > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha2, 8.2.2.Final > > > It seems that some configuration of persistence causes the entry to be expired twice when it should have only expired once. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6394) Coalesce server group view and Infinispan/JGroups view

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6394?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6394: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Coalesce server group view and Infinispan/JGroups view > ------------------------------------------------------ > > Key: ISPN-6394 > URL: https://issues.jboss.org/browse/ISPN-6394 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.0.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Critical > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Currently the console is using the server-group knowledge (i.e. which host/servers belong to a specific group). While that is definitely the "ideal" situation, we also need to ensure that it corresponds to the "actual" cluster as known to Infinispan/JGroups. This information should be then used to present the user with appropriate warnings if necessary. > For each container %c in each server %s in the server group we need to extract the "members" property: > /host=%h/server=%s/subsystem=datagrid-infinispan/cache-container=%c:read-attribute(name=members) > This returns a list of server names (in the form %h:%s). > This is how we should use the information (in combination with the existing "cluster-availability" property information from the coordinator): > 1. If the server-group list coincides with the container members of all nodes, all is good: the cluster is healthy, all nodes are up and running > 2. If all of the container members contain the SAME subset of the server group, but the missing members are in the STOPPED or STARTING state, everything could be normal: we should depend on the coordinator's "cluster-availability" to tell us if the cluster is unhealthy. > 3. If the container members differ between each other and with the server group view, and all these servers are in RUNNING we have a potential split brain or a cluster which is not formed correctly. > The above deduction should determine not only the label / colour-coding we place in the view header (AVAILABLE, DEGRADED, etc) but also some of the view content: in both the cluster nodes view and the cache nodes view we need to group / sort by membership, so that we clearly show split clusters and stopped nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6386) Remove max-entries from the documentation

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6386?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6386: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Remove max-entries from the documentation > ----------------------------------------- > > Key: ISPN-6386 > URL: https://issues.jboss.org/browse/ISPN-6386 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: Sebastian Łaskawiec > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2 > > > In ISPN 9 we use size instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6367) HotRod client unmarshalling ignores configured classloader

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6367?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6367: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > HotRod client unmarshalling ignores configured classloader > ---------------------------------------------------------- > > Key: ISPN-6367 > URL: https://issues.jboss.org/browse/ISPN-6367 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Fix For: 9.0.0.Alpha2 > > > The {{RemoteCacheManager}}'s {{ConfigurationBuilder}} allows you to set a classloader, but the client ignores that classloader when unmarshalling values received from the server. > This leads to problems when the client doesn't have a flat classpath (e.g. in an OSGi or JBoss Modules-based container). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6364) Report test failures on the fly in modules using JUnit

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6364?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6364: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Report test failures on the fly in modules using JUnit > ------------------------------------------------------ > > Key: ISPN-6364 > URL: https://issues.jboss.org/browse/ISPN-6364 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core, Test Suite - Query, Test Suite - Server > Affects Versions: 8.2.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha2 > > > Modules using TestNG for testing use {{UnitTestTestNGListener}} to report test start/finish during the build, making it possible to scan visually for test failures (or just progress). > Modules using JUnit should have this functionality as well. The {{server/integration/testsuite}} module already has a {{RunListener}} that reports the start of a test, it should report failures as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6340) Expose indexing statistics via DMR

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6340?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6340: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > Expose indexing statistics via DMR > ---------------------------------- > > Key: ISPN-6340 > URL: https://issues.jboss.org/browse/ISPN-6340 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6470) CapacityFactorsFunctionalTest.testCapacityFactors random failures

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-6470?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti updated ISPN-6470: ------------------------------------- Fix Version/s: 9.0.0.Alpha2 (was: 9.0.0.Alpha1) > CapacityFactorsFunctionalTest.testCapacityFactors random failures > ------------------------------------------------------------------ > > Key: ISPN-6470 > URL: https://issues.jboss.org/browse/ISPN-6470 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.0.Alpha2 > > > When nodes have different capacity factors, {{SyncConsistentHashFactory}} sometimes has trouble assigning the segments correctly: > {noformat} > java.lang.AssertionError: Expected between:<20.0> and:<50.0> but was:<52.0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.infinispan.test.TestingUtil.assertBetween(TestingUtil.java:1455) > at org.infinispan.distribution.ch.CapacityFactorsFunctionalTest.assertOwned(CapacityFactorsFunctionalTest.java:96) > at org.infinispan.distribution.ch.CapacityFactorsFunctionalTest.testCapacityFactors(CapacityFactorsFunctionalTest.java:65) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2016