January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-2697: -------------------------------- Then call the flag differently, like GUARANTEED_DELIVERY. This is not the user setting this flag, but HotRod, so for me that's totally acceptable. > HotRodServer startup fails when its record cannot be inserted into topology cache > --------------------------------------------------------------------------------- > > Key: ISPN-2697 > URL: https://issues.jboss.org/browse/ISPN-2697 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.2.0.Final > > > When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}). > However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2622) Random failure in RpcManagerMBeanTest

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2622?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-2622. -------------------------------- Resolution: Done The original issue should be fixed because of ISPN-2581. I'm creating a separate issue for the new failure. > Random failure in RpcManagerMBeanTest > ------------------------------------- > > Key: ISPN-2622 > URL: https://issues.jboss.org/browse/ISPN-2622 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Mircea Markus > Priority: Minor > Labels: testsuite_stability > Fix For: 5.3.0.Final > > Attachments: testEnableJmxStats-0.log > > > The test records the replication counter in RpcManagerImpl at the start of the test and after a put operation, and asserts that it only changed by 1. Occasionally, the assertion fails: > {noformat} > java.lang.AssertionError: expected [1] but found [2] > at org.testng.Assert.fail(Assert.java:89) > at org.testng.Assert.failNotEquals(Assert.java:489) > at org.testng.Assert.assertEquals(Assert.java:118) > at org.testng.Assert.assertEquals(Assert.java:160) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:126) > {noformat} > This happens because replication counter is only incremented *after* a successful RPC. The test starts when the cluster is considered "formed", that is when all the nodes are included in the read CH on every node. But that doesn't mean that the RPCs pushing state have finished - a pushing node may still be waiting for a response and so it might increment its replication counter after the start of the test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2697) HotRodServer startup fails when its record cannot be inserted into topology cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2697?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2697: ---------------------------------------- Bela, any user would expect the RPC to be acknowledged if it's sync. I don't see why users need to be aware of this and why/when they should force it. It feels like a lower level JGroups detail leaking to the Infinispan client. Btw, I guess this is precisely what Dan meant that adding such flag is hacky, which I totally agree with. > HotRodServer startup fails when its record cannot be inserted into topology cache > --------------------------------------------------------------------------------- > > Key: ISPN-2697 > URL: https://issues.jboss.org/browse/ISPN-2697 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta6 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 5.2.0.Final > > > When the HotRodServer starts it inserts its record to __hotRodTopologyCache ({{HotRodServer.addSelfToTopologyView(...)}}). > However, this put may very easily fail - as the command is broadcasted using NAKACK2 protocol, if the message gets lost and there's no following broadcasted message, the message will be not retransmitted and the put operation times out (Replication timeout), which fails the whole HotRodServer startup, all because of one lost UDP message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2622) Random failure in RpcManagerMBeanTest

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2622?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2622: ------------------------------------ [~galderz] It doesn't look like a random failure any more, it fails for me every time. There's also a NPE earlier in the log: {noformat} 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled java.lang.NullPointerException at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391) at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325) at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746) at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729) at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134) {noformat} > Random failure in RpcManagerMBeanTest > ------------------------------------- > > Key: ISPN-2622 > URL: https://issues.jboss.org/browse/ISPN-2622 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Mircea Markus > Priority: Minor > Labels: testsuite_stability > Fix For: 5.3.0.Final > > Attachments: testEnableJmxStats-0.log > > > The test records the replication counter in RpcManagerImpl at the start of the test and after a put operation, and asserts that it only changed by 1. Occasionally, the assertion fails: > {noformat} > java.lang.AssertionError: expected [1] but found [2] > at org.testng.Assert.fail(Assert.java:89) > at org.testng.Assert.failNotEquals(Assert.java:489) > at org.testng.Assert.assertEquals(Assert.java:118) > at org.testng.Assert.assertEquals(Assert.java:160) > at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:126) > {noformat} > This happens because replication counter is only incremented *after* a successful RPC. The test starts when the cluster is considered "formed", that is when all the nodes are included in the read CH on every node. But that doesn't mean that the RPCs pushing state have finished - a pushing node may still be waiting for a response and so it might increment its replication counter after the start of the test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2754) Configuration schema error for <loader /> children

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2754?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-2754. ------------------------------------ Resolution: Done > Configuration schema error for <loader /> children > -------------------------------------------------- > > Key: ISPN-2754 > URL: https://issues.jboss.org/browse/ISPN-2754 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 5.2.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > > The <loaders /> element has a child <xs:any /> without a maxOccurs attribute which means that only one cache loader may be specified -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2755) Make sure tableprefix does not contain "non-allowed" characters

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2755?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2755: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks! > Make sure tableprefix does not contain "non-allowed" characters > --------------------------------------------------------------- > > Key: ISPN-2755 > URL: https://issues.jboss.org/browse/ISPN-2755 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2753) Drop the staxmapper dependency

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2753?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2753: ---------------------------------- Status: Open (was: Pull Request Sent) > Drop the staxmapper dependency > ------------------------------ > > Key: ISPN-2753 > URL: https://issues.jboss.org/browse/ISPN-2753 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 5.2.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > > staxmapper is composed of very few classes, of which we only use half. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2753) Drop the staxmapper dependency

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2753?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-2753. ----------------------------------- Resolution: Rejected > Drop the staxmapper dependency > ------------------------------ > > Key: ISPN-2753 > URL: https://issues.jboss.org/browse/ISPN-2753 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 5.2.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.0.Final > > > staxmapper is composed of very few classes, of which we only use half. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2670) Update HotRod test client in server module to work with protocol version 1.2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2670?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2670: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update HotRod test client in server module to work with protocol version 1.2 > ---------------------------------------------------------------------------- > > Key: ISPN-2670 > URL: https://issues.jboss.org/browse/ISPN-2670 > Project: Infinispan > Issue Type: Task > Components: Remote protocols, Test Suite > Affects Versions: 5.2.0.Beta6 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 5.2.0.Final > > > The HotRod server test suite doesn't cover protocol version 1.2, and the test client doesn't actually work with this version. > I created a new test based on HotRodMultiNodeTest and when I changed the version to 12, the first ping operation failed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2581) StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2581?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2581: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon > --------------------------------------------------------------------------------- > > Key: ISPN-2581 > URL: https://issues.jboss.org/browse/ISPN-2581 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Adrian Nistor > Fix For: 5.2.0.Final > > > StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns as soon as a joining node confirmed to the coordinator that it received all the data it needed (see STMI.notifyEndOfTopologyUpdate()). > It should return only after the coordinator has confirmed the end of the rebalance with a new topology update (see STMI.doTopologyUpdate()). > This should make it more likely for the tests suite clusters to be in a stable state by the time the test starts, and should help with the random state transfer-related failures in non-state transfer tests. > Instead we should make sure that we do have tests that check forwarding behaviour explicitly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013