January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3958) ReplTopologyChangeTest.testDropServer random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3958: ---------------------------------- Summary: ReplTopologyChangeTest.testDropServer random failures Key: ISPN-3958 URL: https://issues.jboss.org/browse/ISPN-3958 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 6.0.1.Final Reporter: Dan Berindei Assignee: Mircea Markus Fix For: 7.0.0.Final {{ReplTopologyChangeTest.expectTopologyChange()}} assumes that it will take less than 10 put operations to receive an updated topology after killing a node. Some times, however, that is not enough for the server to send the new topology: {noformat} 21:30:46,438 ERROR (testng-ReplTopologyChangeTest:) [UnitTestTestNGListener] Test testDropServer(org.infinispan.client.hotrod.ReplTopologyChangeTest) failed. java.lang.AssertionError: localhost/127.0.0.1:15269 not found in [/127.0.0.1:15266, /127.0.0.1:15269, /127.0.0.1:15263] expected:<false> but was:<true> 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:185) at org.infinispan.client.hotrod.ReplTopologyChangeTest.expectTopologyChange(ReplTopologyChangeTest.java:141) at org.infinispan.client.hotrod.ReplTopologyChangeTest.testDropServer(ReplTopologyChangeTest.java:123) {noformat} -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3947: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 7.0.0.Final Resolution: Done > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3956: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1059814|https://bugzilla.redhat.com/show_bug.cgi?id=1059814] from NEW to POST > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3947: ----------------------------------------------- Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1058887|https://bugzilla.redhat.com/show_bug.cgi?id=1058887] from NEW to POST > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3956: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059814 > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3947: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/2360, https://github.com/infinispan/infinispan/pull/2367 (was: https://github.com/infinispan/infinispan/pull/2360) > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3947: ------------------------------- Priority: Critical (was: Major) > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3956: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3956: ------------------------------- Forum Reference: https://community.jboss.org/thread/236590 > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3881) Remove references to startserver.sh from the documentation

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3881?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3881: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2366 > Remove references to startserver.sh from the documentation > ---------------------------------------------------------- > > Key: ISPN-3881 > URL: https://issues.jboss.org/browse/ISPN-3881 > Project: Infinispan > Issue Type: Feature Request > Components: Documentation-Core > Reporter: Mircea Markus > Assignee: Tristan Tarrant > > The 6.0 documentation still contains references to the startserver.sh script. > All these should be removed and replaced with a link to how the servers should be started based on WF. -- 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, 10 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 2014