April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5355) BackupForNotSpecifiedTest.testDataGetsReplicated always fails

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5355?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5355: ---------------------------------- Status: Open (was: New) > BackupForNotSpecifiedTest.testDataGetsReplicated always fails > ------------------------------------------------------------- > > Key: ISPN-5355 > URL: https://issues.jboss.org/browse/ISPN-5355 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.2.0.CR1 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 7.2.0.CR1 > > > The test seems to be failing since the fix for ISPN-5243 was integrated in master: > {noformat} > java.lang.AssertionError: expected:<v_backup_lon> but was:<null> > 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.xsite.BackupForNotSpecifiedTest.testDataGetsReplicated(BackupForNotSpecifiedTest.java:67) > {noformat} > http://ci.infinispan.org/viewLog.html?buildId=24683&buildTypeId=bt8&tab=b... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5009) Upgrade server base to WildFly 9.0.0.Beta2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5009?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5009: ---------------------------------------- I've done some work to try to upgrade to WF9: https://github.com/galderz/infinispan/tree/z_5009 However, configuration assembly has changed completely in WF9 and now requires defining a feature pack. [~NadirX] will continue with this since doing this requires intimate knowledge server structure and components to get it right. > Upgrade server base to WildFly 9.0.0.Beta2 > ------------------------------------------ > > Key: ISPN-5009 > URL: https://issues.jboss.org/browse/ISPN-5009 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 8.0.0.Final > > > Originally it was meant to upgrade to Wildfly 8.2.0.Final but some issues where found. Upgrade still needed but upgrading to 9.0.0.Beta2 which solves issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5009) Upgrade server base to WildFly 9.0.0.Beta2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5009?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-5009: -------------------------------------- Assignee: Tristan Tarrant (was: Galder Zamarreño) > Upgrade server base to WildFly 9.0.0.Beta2 > ------------------------------------------ > > Key: ISPN-5009 > URL: https://issues.jboss.org/browse/ISPN-5009 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > Originally it was meant to upgrade to Wildfly 8.2.0.Final but some issues where found. Upgrade still needed but upgrading to 9.0.0.Beta2 which solves issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5009) Upgrade server base to WildFly 9.0.0.Beta2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5009?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5009: ----------------------------------- Fix Version/s: 8.0.0.Final (was: 7.2.0.Final) (was: 7.2.0.CR1) > Upgrade server base to WildFly 9.0.0.Beta2 > ------------------------------------------ > > Key: ISPN-5009 > URL: https://issues.jboss.org/browse/ISPN-5009 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > Originally it was meant to upgrade to Wildfly 8.2.0.Final but some issues where found. Upgrade still needed but upgrading to 9.0.0.Beta2 which solves issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5009) Upgrade server base to WildFly 9.0.0.Beta2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5009?page=com.atlassian.jira.plugin.... ] Work on ISPN-5009 stopped by Galder Zamarreño. ---------------------------------------------- > Upgrade server base to WildFly 9.0.0.Beta2 > ------------------------------------------ > > Key: ISPN-5009 > URL: https://issues.jboss.org/browse/ISPN-5009 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Server > Affects Versions: 7.0.2.Final > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Fix For: 7.2.0.CR1, 7.2.0.Final > > > Originally it was meant to upgrade to Wildfly 8.2.0.Final but some issues where found. Upgrade still needed but upgrading to 9.0.0.Beta2 which solves issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5371) Cache.putAll doesn't work properly when combatibility is enabled

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5371?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5371: -------------------------------- Status: Open (was: New) > Cache.putAll doesn't work properly when combatibility is enabled > ---------------------------------------------------------------- > > Key: ISPN-5371 > URL: https://issues.jboss.org/browse/ISPN-5371 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.2.0.CR1 > > > The Type Converter interceptor doesn't currently box entries for the putMap command. This causes putAll to store values incorrectly and therefore do not work with compatibility. > This has most likely gone unnoticed since it would only be visible when using a hybrid server where an embedded client and calls putAll. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5371) Cache.putAll doesn't work properly when combatibility is enabled

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5371?page=com.atlassian.jira.plugin.... ] Work on ISPN-5371 started by William Burns. ------------------------------------------- > Cache.putAll doesn't work properly when combatibility is enabled > ---------------------------------------------------------------- > > Key: ISPN-5371 > URL: https://issues.jboss.org/browse/ISPN-5371 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.2.0.CR1 > > > The Type Converter interceptor doesn't currently box entries for the putMap command. This causes putAll to store values incorrectly and therefore do not work with compatibility. > This has most likely gone unnoticed since it would only be visible when using a hybrid server where an embedded client and calls putAll. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5371) Cache.putAll doesn't work properly when combatibility is enabled

by William Burns (JIRA)

William Burns created ISPN-5371: ----------------------------------- Summary: Cache.putAll doesn't work properly when combatibility is enabled Key: ISPN-5371 URL: https://issues.jboss.org/browse/ISPN-5371 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.1.1.Final Reporter: William Burns Assignee: William Burns Fix For: 7.2.0.CR1 The Type Converter interceptor doesn't currently box entries for the putMap command. This causes putAll to store values incorrectly and therefore do not work with compatibility. This has most likely gone unnoticed since it would only be visible when using a hybrid server where an embedded client and calls putAll. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5365) JmxManagementIT.testCacheStatisticsAttributes always fails

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-5365?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-5365: -------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3371 > JmxManagementIT.testCacheStatisticsAttributes always fails > ----------------------------------------------------------- > > Key: ISPN-5365 > URL: https://issues.jboss.org/browse/ISPN-5365 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.2.0.CR1 > > > Looks like the {{ElapsedTime}} attribute got renamed to {{TimeSinceStart}}, and {{JmxManagementIT}} still uses the old name: > {noformat} > javax.management.AttributeNotFoundException: Unknown attribute 'ElapsedTime'. Known attributes names are: [numberOfEntries, averageReadTime, hitRatio, timeSinceReset, averageRemoveTime, misses, evictions, readWriteRatio, statisticsEnabled, hits, timeSinceStart, removeMisses, removeHits, stores, averageWriteTime] > at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:181) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.getAttribute(PluggableMBeanServerImpl.java:1377) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:384) > at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetAttributeHandler.handle(ServerProxy.java:691) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:415) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) > at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > I think maybe we should keep the old attribute name as well, for backwards compatibility. I'm thinking RHQ might use it... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-5021: ----------------------------------- It generates conflicts in the code. Lets integrate the ISPN-5046 first > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.2.0.CR1 > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 April 2015