December 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5981) Compatibility mode: HotRod client sends request to wrong owner

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5981?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5981: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3893, https://github.com/infinispan/infinispan/pull/3898 (was: https://github.com/infinispan/infinispan/pull/3893) > Compatibility mode: HotRod client sends request to wrong owner > -------------------------------------------------------------- > > Key: ISPN-5981 > URL: https://issues.jboss.org/browse/ISPN-5981 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 8.2.0.Alpha1, 8.2.0.Final > > Attachments: GetAllCompatDistTest.java > > > The HotRod client computes the hash on the serialized key, i.e. {{MurmurHash3.hash(obj2bytes(key))}}, but the server decides the entry location based on the unmarshalled key, i.e. {{MurmurHash3.hash(key.hashCode())}}. > I've modified {{GetAllCompatDistTest}} (attached) to test if there are any {{ClusteredGetCommand}}s being sent for {{RemoteCache.get(key)}} operations, and it finds quite a few: > {noformat} > java.lang.AssertionError: expected:<100> but was:<147> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.8.8.jar:?] > at org.infinispan.client.hotrod.GetAllCompatDistTest.testGetWithCompatibility(GetAllCompatDistTest.java:57) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6027) Use bundler sender-sends-with-timer by default

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6027?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6027: ------------------------------------ Turns out we use {{OOB | DONT_BUNDLE}}, which disables bundling on the sender side *only* when {{sender-sends-with-timer}} is selected. That would explain why {{sender-sends-with-timer}} improves the throughput, even if it's actually being worse than {{transfer-queue}} when it's in use! > Use bundler sender-sends-with-timer by default > ---------------------------------------------- > > Key: ISPN-6027 > URL: https://issues.jboss.org/browse/ISPN-6027 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > Performance tests show {{sender-sends-with-timer}} is still a bit faster than {{transfer-queue}}, so we should make it the default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6027) Use bundler sender-sends-with-timer by default

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6027?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6027: ------------------------------------ [~belaban] It was a {{radargun}} test with 4 nodes, testing via HotRod, the cache was replicated, and the get:put ratio was 2:1. I didn't realize {{sender-sends-with-timer}} was on its way out in 4.0. TBH this was a bit of a rush decision because we've noticed a regression on the product side, but we should definitely investigate the bundlers more for JGRP-1997. > Use bundler sender-sends-with-timer by default > ---------------------------------------------- > > Key: ISPN-6027 > URL: https://issues.jboss.org/browse/ISPN-6027 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > Performance tests show {{sender-sends-with-timer}} is still a bit faster than {{transfer-queue}}, so we should make it the default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5981) Compatibility mode: HotRod client sends request to wrong owner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5981?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5981: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1285381|https://bugzilla.redhat.com/show_bug.cgi?id=1285381] from POST to MODIFIED > Compatibility mode: HotRod client sends request to wrong owner > -------------------------------------------------------------- > > Key: ISPN-5981 > URL: https://issues.jboss.org/browse/ISPN-5981 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.0.1.Final, 8.1.0.Beta1 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 8.2.0.Alpha1, 8.2.0.Final > > Attachments: GetAllCompatDistTest.java > > > The HotRod client computes the hash on the serialized key, i.e. {{MurmurHash3.hash(obj2bytes(key))}}, but the server decides the entry location based on the unmarshalled key, i.e. {{MurmurHash3.hash(key.hashCode())}}. > I've modified {{GetAllCompatDistTest}} (attached) to test if there are any {{ClusteredGetCommand}}s being sent for {{RemoteCache.get(key)}} operations, and it finds quite a few: > {noformat} > java.lang.AssertionError: expected:<100> but was:<147> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.8.8.jar:?] > at org.infinispan.client.hotrod.GetAllCompatDistTest.testGetWithCompatibility(GetAllCompatDistTest.java:57) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6027) Use bundler sender-sends-with-timer by default

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-6027?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-6027: -------------------------------- No! I deprecated this bundler and it will be removed in 4.0. Which perf test are you referring to? > Use bundler sender-sends-with-timer by default > ---------------------------------------------- > > Key: ISPN-6027 > URL: https://issues.jboss.org/browse/ISPN-6027 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > Performance tests show {{sender-sends-with-timer}} is still a bit faster than {{transfer-queue}}, so we should make it the default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6027) Use bundler sender-sends-with-timer by default

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6027?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6027: ------------------------------- Status: Open (was: New) > Use bundler sender-sends-with-timer by default > ---------------------------------------------- > > Key: ISPN-6027 > URL: https://issues.jboss.org/browse/ISPN-6027 > Project: Infinispan > Issue Type: Task > Components: Configuration, Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1 > > > Performance tests show {{sender-sends-with-timer}} is still a bit faster than {{transfer-queue}}, so we should make it the default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6027) Use bundler sender-sends-with-timer by default

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6027: ---------------------------------- Summary: Use bundler sender-sends-with-timer by default Key: ISPN-6027 URL: https://issues.jboss.org/browse/ISPN-6027 Project: Infinispan Issue Type: Task Components: Configuration, Core Affects Versions: 8.1.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.2.0.Alpha1 Performance tests show {{sender-sends-with-timer}} is still a bit faster than {{transfer-queue}}, so we should make it the default. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6003) Reduce number of allocations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6003?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6003: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Reduce number of allocations > ---------------------------- > > Key: ISPN-6003 > URL: https://issues.jboss.org/browse/ISPN-6003 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > Profiling revealed some allocations that are easy to remove: > * The HotRod operations factory stores a list of flags in a thread-local. The thread-local can be removed, and the flags can be stored in an {{int}}. > * JGroupsTransport copies the list of members to check if a broadcast should be sent as a unicast, and the copy is then discarded. > * ExtendedByteBuf could use {{Array.empty}} instead of {{Array[Byte]()}}. > * DecoratedCache could avoid calling {{Arrays.asList()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5860) ComponentRegistry should cache the VersionGenerator in a field

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5860?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5860: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > ComponentRegistry should cache the VersionGenerator in a field > -------------------------------------------------------------- > > Key: ISPN-5860 > URL: https://issues.jboss.org/browse/ISPN-5860 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The {{VersionGenerator}} component is read by the HotRod server for each write operation, and we can optimize it by caching the component in a field. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6002) Cache log.isTraceEnabled() as much as possible

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6002?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6002: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from POST to MODIFIED > Cache log.isTraceEnabled() as much as possible > ---------------------------------------------- > > Key: ISPN-6002 > URL: https://issues.jboss.org/browse/ISPN-6002 > Project: Infinispan > Issue Type: Task > Components: Core, Server > Affects Versions: 8.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 8.1.0.Final > > > With log4j2 it's not that big of a problem, but there are still environments where this could make a difference (i.e. in the server). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015