July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4492) Unable to parse queue-size in LevelDB store

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-4492: --------------------------------- Summary: Unable to parse queue-size in LevelDB store Key: ISPN-4492 URL: https://issues.jboss.org/browse/ISPN-4492 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Loaders and Stores Affects Versions: 7.0.0.Alpha4 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 7.0.0.Alpha5 In server, the queue-size attribute is not correctly parsed from configuration file. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4489) TestNG OOME on large number of failures

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4489?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4489: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2699 > TestNG OOME on large number of failures > --------------------------------------- > > Key: ISPN-4489 > URL: https://issues.jboss.org/browse/ISPN-4489 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > > If for some reason several tests fail testng will throw an OOME. > {noformat} > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2367) > at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) > at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) > at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:415) > at java.lang.StringBuilder.append(StringBuilder.java:132) > at org.testng.reporters.Files.readFile(Files.java:28) > at org.testng.reporters.Files.readFile(Files.java:20) > at org.testng.reporters.FileStringBuffer.toString(FileStringBuffer.java:137) > at org.testng.reporters.XMLStringBuffer.toXML(XMLStringBuffer.java:331) > at org.testng.reporters.jq.ChronologicalPanel.getContent(ChronologicalPanel.java:93) > at org.testng.reporters.jq.BaseMultiSuitePanel.generate(BaseMultiSuitePanel.java:24) > at org.testng.reporters.jq.Main.generateReport(Main.java:63) > at org.testng.TestNG.generateReports(TestNG.java:1115) > at org.testng.TestNG.run(TestNG.java:1074) > at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115) > at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:204) > at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:107) > at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:112) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > {noformat} > This particular error is triggered by one of the reports enabled by default by testng which is producing a more user friendly version using jquery. > Since we are probably don't need this report look into disabling it. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4480) Messages sent to leavers can clog the JGroups bundler thread

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4480?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4480: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from ON_QA to ASSIGNED > Messages sent to leavers can clog the JGroups bundler thread > ------------------------------------------------------------ > > Key: ISPN-4480 > URL: https://issues.jboss.org/browse/ISPN-4480 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > > In a stress test that repeatedly kills nodes while performing read/write operations, the TransferQueueBundler thread seems to spend a lot of time waiting for physical addresses: > {noformat} > 06:40:10,316 WARN [org.radargun.utils.Utils] (pool-5-thread-1) Stack for thread TransferQueueBundler,default,apex953-14666: > java.lang.Thread.sleep(Native Method) > org.jgroups.util.Util.sleep(Util.java:1504) > org.jgroups.util.Util.sleepRandom(Util.java:1574) > org.jgroups.protocols.TP.sendToSingleMember(TP.java:1685) > org.jgroups.protocols.TP.doSend(TP.java:1670) > org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2476) > org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2392) > org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2383) > java.lang.Thread.run(Thread.java:744) > {noformat} > There are 2 bugs related to this already fixed in JGroups 3.5.0.Beta2+: JGRP-1814, JGRP-1815 > There is also a special case where the physical address could be removed from the cache too soon, exacerbating the effect of JGRP-1815: JGRP-1858 > We can work around the problem by changing the JGroups configuration: > * TP.logical_addr_cache_expiration=86400000 > ** Only expire addresses after 1 day > * TP.physical_addr_max_fetch_attempts=1 > ** Sleep for only 20ms waiting for the physical address (default 3 - 1500ms) > * UNICAST3_conn_close_timeout=10000 > ** Drop the pending messages to leavers sooner -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4484) Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4484?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4484: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from ON_QA to ASSIGNED > Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command > ------------------------------------------------------------------------ > > Key: ISPN-4484 > URL: https://issues.jboss.org/browse/ISPN-4484 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > This appeared during the 32-nodes elasticity test in the Hyperion environment. > Just as apex947 left, it started a rebalance, which apex948 dutifully cancelled as it became the new coordinator. apex949 had already requested segments from apex959, so it sent a StateRequestCommand(CANCEL_STATE_TRANSFER) asynchronously to apex959. Then apex948 started a new rebalance, and apex949 asked apex959 for the same segments. When apex959 finally received the cancel request, it didn't check the topology id and it incorrectly cancelled the outbound transfer to apex949. > The solution would be to verify the topology id in the CANCEL_STATE_TRANSFER command before cancelling the transfer. I also think we can avoid sending the cancel command completely in this case, and only send it as we are about to stop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4154) Cancelled segment transfer causes future entry transfer to be ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4154?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4154: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from ON_QA to ASSIGNED > Cancelled segment transfer causes future entry transfer to be ignored > --------------------------------------------------------------------- > > Key: ISPN-4154 > URL: https://issues.jboss.org/browse/ISPN-4154 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > Distributed transactional cache. > 1) Coordinator is gracefully leaving the cluster, sends a REBALANCE_START with topologyId 14, ST begins. > 2) Node receives chunk from segment X, writes entry K=V to the container. > 3) New coordinator jumps in with CH_UPDATE topology 16 > 4) Node receives CANCEL_STATE_TRANSFER and cancels transfer of segment X, invalidating K. In CommitManager, this operation is tracked and DiscardPolicy is set to DISCARD_STATE_TRANSFER for key K. > 5) New coordinator starts rebalance with topology 17 > 6) Node starts new ST for segment X > 7) Node receives the X: K=V, but in CommitManager it finds out that the policy is set to DISCARD_STATE_TRANSFER and ignores this update. > Result: entry value is lost on some node. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4200) ExampleConfigsTest.testRestRollingUpgrades fails

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4200?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-4200: ------------------------------------ "Pure" RestRollingUpgradesIT passes even with both configs with compatibility enabled. The issue is that we are storing data using HotRod (in example config test) and then trying to get it through REST store. > ExampleConfigsTest.testRestRollingUpgrades fails > ------------------------------------------------ > > Key: ISPN-4200 > URL: https://issues.jboss.org/browse/ISPN-4200 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Reporter: Jakub Markos > Assignee: Mircea Markus > > Fails in the latest snapshot on line 240 with > {code} > Can't access etries stored in source node (target's RestCacheStore). expected:<value1> but was:<[B@19676adb> > {code} > you can run the test from /server/integration/testsuite with this command: > mvn clean test -Psuite.examples -Dtest=ExampleConfigsTest#testRestRollingUpgrades > The configs used are /server/integration/testsuite/target/server/node1/standalone/configuration/examples/{standalone-rest-rolling-upgrade.xml, standalone-compatibility-mode.xml} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4426) Transaction replayed but not committed

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4426?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4426: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > Transaction replayed but not committed > -------------------------------------- > > Key: ISPN-4426 > URL: https://issues.jboss.org/browse/ISPN-4426 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 63gablocker > Fix For: 7.0.0.Alpha5 > > > Dist TX cache, node C is joining. In previous topology, entry is owned by A (primary) and B (backup). In new topology, primary ownership is transferred to C, B stays backup. > 1. TX is prepared in old topology and is being committed, when topology changes > 2. on C (the new owner), the TX info is received and later even the old entry > 3. C receives the CommitCommand, therefore, it correctly replays the PrepareCommand. > 4. When the entries are about to be committed, in TxInterceptor the transaction is found to be already completed as it has lower TxID. > Result: the transaction is not being executed and stale data stay on the node (with my algortihm it eventually led to complete entry loss). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4481) Use UNICAST3 and NAKACK2 in the default server configuration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4481?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4481: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use UNICAST3 and NAKACK2 in the default server configuration > ------------------------------------------------------------ > > Key: ISPN-4481 > URL: https://issues.jboss.org/browse/ISPN-4481 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > We switched to UNICAST3 a while back in the default embedded configuration, we should switch the server configuration as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4484) Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4484?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4484: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Outbound transfers can be cancelled by old CANCEL_STATE_TRANSFER command > ------------------------------------------------------------------------ > > Key: ISPN-4484 > URL: https://issues.jboss.org/browse/ISPN-4484 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > This appeared during the 32-nodes elasticity test in the Hyperion environment. > Just as apex947 left, it started a rebalance, which apex948 dutifully cancelled as it became the new coordinator. apex949 had already requested segments from apex959, so it sent a StateRequestCommand(CANCEL_STATE_TRANSFER) asynchronously to apex959. Then apex948 started a new rebalance, and apex949 asked apex959 for the same segments. When apex959 finally received the cancel request, it didn't check the topology id and it incorrectly cancelled the outbound transfer to apex949. > The solution would be to verify the topology id in the CANCEL_STATE_TRANSFER command before cancelling the transfer. I also think we can avoid sending the cancel command completely in this case, and only send it as we are about to stop. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4469) StateConsumerImpl segment change tracing is incorrect

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4469?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4469: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Dan Berindei (was: Mircea Markus) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > StateConsumerImpl segment change tracing is incorrect > ----------------------------------------------------- > > Key: ISPN-4469 > URL: https://issues.jboss.org/browse/ISPN-4469 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > StateConsumerImpl has some tracing to tell you what segments had changed. Unfortunately the arguments are in the wrong order and can cause some confusion. > {code} > if (trace) { > log.tracef("On cache %s we have: new segments: %s; old segments: %s; removed segments: %s; added segments: %s", > cacheName, removedSegments, newSegments, previousSegments, addedSegments); > } > {code} > It should be newSegments, previousSegments, removedSegments, addedSegments instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014