May 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6124) List of caches is sometimes visually corrupt

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6124?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-6124. -------------------------------- Fix Version/s: 9.0.0.Alpha2 Resolution: Done > List of caches is sometimes visually corrupt > -------------------------------------------- > > Key: ISPN-6124 > URL: https://issues.jboss.org/browse/ISPN-6124 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Final > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2 > > Attachments: Snímek z 2016-01-29 11-37-21.png > > > Page: Cache -> select some container -> list of caches > Under certain circumstances, the cache cards are wrongly aligned, see the screenshot in attachments. I think it's because those two caches on the right don't have any icons below the cache type, making the box smaller. > The solution would be to assign fixed height, since it can be predictable or add a "clearing" div after each row, I guess. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-6580 at 5/5/16 11:49 AM: -------------------------------------------------------------- Removing the executor group and replacing with a single downstream only execution handler seems to get the rest of the get performance back in line. Changes can be found at https://github.com/wburns/infinispan/commit/b6f214cb28fd250de9e31878acd70... was (Author: william.burns): Removing the executor group and replacing with a single downstream only execution handler seems to get the rest of the get performance back in line. Changes can be found at b6f214cb28fd250de9e31878acd709fbb99d1906 > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-6580: ------------------------------------- Removing the executor group and replacing with a single downstream only execution handler seems to get the rest of the get performance back in line. Changes can be found at b6f214cb28fd250de9e31878acd709fbb99d1906 > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5916) Filtering by cache status in management console doesn't work

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-5916?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-5916: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/96 > Filtering by cache status in management console doesn't work > ------------------------------------------------------------ > > Key: ISPN-5916 > URL: https://issues.jboss.org/browse/ISPN-5916 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2 > > > Page: "Caches" tab -> click on certain cache container: list of caches in that container is shown. > On the left side, these are options how to filter the shown caches and you can also filter by cache status - Indexing, Offline, Rebalancing, Split. When I click any of them, nothing happens, it looks like they do nothing since I definitely don't have any cache rebalancing or indexed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5916) Filtering by cache status in management console doesn't work

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-5916?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-5916: ------------------------------- Status: Open (was: New) > Filtering by cache status in management console doesn't work > ------------------------------------------------------------ > > Key: ISPN-5916 > URL: https://issues.jboss.org/browse/ISPN-5916 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2 > > > Page: "Caches" tab -> click on certain cache container: list of caches in that container is shown. > On the left side, these are options how to filter the shown caches and you can also filter by cache status - Indexing, Offline, Rebalancing, Split. When I click any of them, nothing happens, it looks like they do nothing since I definitely don't have any cache rebalancing or indexed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5916) Filtering by cache status in management console doesn't work

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-5916?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-5916. -------------------------------- Fix Version/s: 9.0.0.Alpha2 Resolution: Done > Filtering by cache status in management console doesn't work > ------------------------------------------------------------ > > Key: ISPN-5916 > URL: https://issues.jboss.org/browse/ISPN-5916 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha2 > > > Page: "Caches" tab -> click on certain cache container: list of caches in that container is shown. > On the left side, these are options how to filter the shown caches and you can also filter by cache status - Indexing, Offline, Rebalancing, Split. When I click any of them, nothing happens, it looks like they do nothing since I definitely don't have any cache rebalancing or indexed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-6580: ------------------------------------- The second issue is fixed by https://github.com/wburns/infinispan/commit/b07e26784543550131d5828e88243... The first issue I can mitigate the get performance, but it wasn't fully the same with https://github.com/wburns/infinispan/commit/a29be7d1cf4c93655033e1d29f7be... > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-6040: ------------------------------------------- Ignored by https://github.com/infinispan/infinispan/pull/4311 > FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6040 > URL: https://issues.jboss.org/browse/ISPN-6040 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Alpha2 > > > Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove. > In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove. > {noformat} > java.lang.AssertionError: expected:<null> but was:<v0> > 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.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194) > at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6580: ------------------------------------ [~william.burns] async interceptors are almost ready, so in theory we'll be able to run everything on the socket read thread. Of course, we're still missing an async SPI for the cache loaders, but I hope we'll also have async SPIs for those for 9.0. For now, I would go ahead and invoke read operations on the netty socket read thread, as we have 2 x cores of those (I think), and data container misses should be pretty rare - except for performance tests that access keys using a uniform distribution ;) > Hotrod performance regressions after ISPN-5342 ISPN-6545 > -------------------------------------------------------- > > Key: ISPN-6580 > URL: https://issues.jboss.org/browse/ISPN-6580 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: William Burns > Attachments: jfr_recordings.zip, pom.xml, Reproducer.java > > > There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact... > It is easily reproducable locally with a single server instance, reproducer attached. > The numbers on my machine: > ||Build commit||Puts time||Gets time|| > |dd5501c5e|21|74| > |628819461|26|102| > |db0890270|48|224| > The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6595) Simplify CDI default bean implementation

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-6595: ----------------------------------------- Summary: Simplify CDI default bean implementation Key: ISPN-6595 URL: https://issues.jboss.org/browse/ISPN-6595 Project: Infinispan Issue Type: Enhancement Components: CDI Integration Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec Fix For: 9.0.0.Alpha3 The main idea is to remove {{DefaultEmbeddedCacheManagerProducer}} and add them only if necessary (we can check that by {{BeanManager.getBeans(EmbeddedCacheManager.class)}} ) in {{AfterBeanDiscovery}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016