September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-3125) SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3125?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-3125: -------------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/2918 (was: https://github.com/infinispan/infinispan/pull/2771) > SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config > -------------------------------------------------------------------------------------- > > Key: ISPN-3125 > URL: https://issues.jboss.org/browse/ISPN-3125 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Reporter: Mike Noordermeer > Assignee: Sebastian Łaskawiec > Priority: Minor > > The SpringEmbeddedCacheManager contains the following comment: > bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings. > In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}. > I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297 > It seems the same issue exists in {{InfinispanNamedEmbeddedCacheFactoryBean}}, there configuration overrides don't seem to be applied if {{configurationTemplateMode == DEFAULT}}, or {{configurationTemplateMode == NAMED}}, whereas the documentation says that should work. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4633) Local transaction not removed from transaction table after a size() operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4633?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4633: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1147634|https://bugzilla.redhat.com/show_bug.cgi?id=1147634] from NEW to POST > Local transaction not removed from transaction table after a size() operation > ----------------------------------------------------------------------------- > > Key: ISPN-4633 > URL: https://issues.jboss.org/browse/ISPN-4633 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Executing cache.size() as the only operation during a transaction will leave behind a LocalTransaction in the transaction table. This tx has not locked keys and will eventually be removed by the reaper after a while. The same fix as for ISPN-4196 should be applied for size(). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3125) SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3125?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-3125: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Olaf Bergner) > SpringEmbeddedCacheManagerFactoryBean does not allow overrides when referencing config > -------------------------------------------------------------------------------------- > > Key: ISPN-3125 > URL: https://issues.jboss.org/browse/ISPN-3125 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 5.3.0.Beta2 > Reporter: Mike Noordermeer > Assignee: Sebastian Łaskawiec > Priority: Minor > > The SpringEmbeddedCacheManager contains the following comment: > bq. A user may further customize the SpringEmbeddedCacheManager's configuration using explicit setters on this FactoryBean. The properties thus defined will be applied either to the configuration loaded from Infinispan's configuration file in case one has been specified, or to a configuration initialized with Infinispan's default settings. Either way, the net effect is that explicitly set configuration properties take precedence over both those loaded from a configuration file as well as INFNISPAN's default settings. > In this current version, setting a configfile + overriding properties does not seem to be possible. This can also be seen in {{AbstractEmbeddedCacheManagerFactory.createBackingEmbeddedCacheManager()}}, where the overrides are only applied iff {{configurationFileLocation == null}}. > I made a little workaround to fix this issue, but it's a mess because the {{DefaultCacheManager}} does not seem to allow overriding values if it gets its config from an InputStream. The workaround is available at https://gist.github.com/MikeN123/5618297 > It seems the same issue exists in {{InfinispanNamedEmbeddedCacheFactoryBean}}, there configuration overrides don't seem to be applied if {{configurationTemplateMode == DEFAULT}}, or {{configurationTemplateMode == NAMED}}, whereas the documentation says that should work. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4776) The topology id for the merged cache topology is not always bigger than all the partition topology ids

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4776?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4776: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > The topology id for the merged cache topology is not always bigger than all the partition topology ids > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-4776 > URL: https://issues.jboss.org/browse/ISPN-4776 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > With the ISPN-4574 fix, I changed the merge algorithm to pick the partition with the most members (both in the _stable_ topology and in the _current_ topology) instead of the partition with the highest topology id. > However, the biggest topology is not necessarily the partition with the highest topology id, so it's possible that some nodes will ignore the merged topology because they already have a higher topology installed. This happened once in ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit: > {noformat} > 00:24:59,286 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Recovered 3 partition(s) for cache cache: [CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeL-25322: 60+0]}, pendingCH=null, unionCH=null}, CacheTopology{id=6, rebalanceId=3, currentCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+10, NodeN-6727: 30+10]}, pendingCH=DefaultConsistentHash{ns = 60, owners = (2)[, NodeL-25322: 30+30, NodeN-6727: 30+30]}, unionCH=null}, CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}] > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterCacheStatus] Updating topologies after merge for cache cache, current topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, stable topology = CacheTopology{id=4, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (3)[, NodeL-25322: 20+20, NodeM-12972: 20+20, NodeN-6727: 20+20]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,287 DEBUG (transport-thread-NodeL-p33097-t6:) [ClusterTopologyManagerImpl] Updating cluster-wide current topology for cache cache, topology = CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null}, availability mode = null > 00:24:59,288 TRACE (transport-thread-NodeL-p33097-t3:) [LocalTopologyManagerImpl] Ignoring consistent hash update for cache cache, current topology is 8: CacheTopology{id=5, rebalanceId=2, currentCH=DefaultConsistentHash{ns = 60, owners = (1)[, NodeM-12972: 60+0]}, pendingCH=null, unionCH=null} > {noformat} > Failure logs here: http://ci.infinispan.org/viewLog.html?buildId=12364&buildTypeId=Infinispa... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4760) Cluster registry doesn't work when rebalancing is disabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4760?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4760: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Cluster registry doesn't work when rebalancing is disabled > ---------------------------------------------------------- > > Key: ISPN-4760 > URL: https://issues.jboss.org/browse/ISPN-4760 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > I accidentally reverted the ISPN-4389 fix when I deleted the RebalancePolicy for ISPN-4574. > The only affected test seems to be StateTransferSuppressIT, but there is an unrelated failure earlier in the test masking it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4754) Module dependency to Hibernate Search should use slot version 5.0

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4754?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4754: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2916 > Module dependency to Hibernate Search should use slot version 5.0 > ----------------------------------------------------------------- > > Key: ISPN-4754 > URL: https://issues.jboss.org/browse/ISPN-4754 > Project: Infinispan > Issue Type: Task > Components: Build process > Affects Versions: 7.0.0.Beta2 > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Priority: Blocker > Fix For: 7.0.0.CR1 > > > As discussed on the mailing list: > http://lists.jboss.org/pipermail/infinispan-dev/2014-September/015390.html > as we otherwise get a duplicate version of hibernate-search-engine on the classpath when people intend to use Infinispan modules to store Search indexes generated by an Hibernate Search "normal" distribution. > Also integration tests of Infinispan should download and use the Hibernate Search distribution of its modules for WildFly, rather than bundling custom ones. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4633) Local transaction not removed from transaction table after a size() operation

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4633?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4633: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Local transaction not removed from transaction table after a size() operation > ----------------------------------------------------------------------------- > > Key: ISPN-4633 > URL: https://issues.jboss.org/browse/ISPN-4633 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.CR1 > > > Executing cache.size() as the only operation during a transaction will leave behind a LocalTransaction in the transaction table. This tx has not locked keys and will eventually be removed by the reaper after a while. The same fix as for ISPN-4196 should be applied for size(). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4574) PartitionHandling: consider less than numOwners partitions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4574?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4574: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147885 > PartitionHandling: consider less than numOwners partitions > ---------------------------------------------------------- > > Key: ISPN-4574 > URL: https://issues.jboss.org/browse/ISPN-4574 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Labels: partition_handling > Fix For: 7.0.0.Beta2 > > > If the following two conditions are simultaneously met during a split brain: > a) less than numOwners nodes leave > b) two clusters are formed having that size > Then both partitions would be considered as available. E.g. a cluster of 6 nodes with numOwners=4, with a split brain resulting in 3 and 3 nodes partitions. > We should add some logic to prevent this situation, e.g. by requiring the remaining partition to have at least numOwners members. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-263) Handle cluster partitions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-263?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated ISPN-263: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147885 > Handle cluster partitions > ------------------------- > > Key: ISPN-263 > URL: https://issues.jboss.org/browse/ISPN-263 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Manik Surtani > Assignee: Dan Berindei > Labels: MERGE, roadmap, split_brain > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well. > Analogous to JBCACHE-471 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4026) ExampleConfigsTest.testSSLHotRodConfig random failures

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-4026?page=com.atlassian.jira.plugin.... ] Jakub Markos updated ISPN-4026: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2883 > ExampleConfigsTest.testSSLHotRodConfig random failures > ------------------------------------------------------- > > Key: ISPN-4026 > URL: https://issues.jboss.org/browse/ISPN-4026 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Jakub Markos > Priority: Blocker > Fix For: 7.0.0.CR1 > > > {noformat} > org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketException: Connection reset > org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketException: Connection reset > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.flush(TcpTransport.java:157) > at org.infinispan.client.hotrod.impl.operations.PingOperation.execute(PingOperation.java:42) > at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:16) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) > at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:634) > at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:615) > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:526) > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:522) > at org.infinispan.server.test.util.RemoteCacheManagerFactory.createCache(RemoteCacheManagerFactory.java:26) > at org.infinispan.server.test.configs.ExampleConfigsTest.createCache(ExampleConfigsTest.java:753) > at org.infinispan.server.test.configs.ExampleConfigsTest.testSSLHotRodConfig(ExampleConfigsTest.java:402) > {noformat} > http://ci.infinispan.org/viewLog.html?buildId=6642&tab=buildResultsDiv&bu... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014