January 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-6062: ------------------------------ Status: Open (was: New) > Remove megamorphic calls when calling next method in interceptor stack > ---------------------------------------------------------------------- > > Key: ISPN-6062 > URL: https://issues.jboss.org/browse/ISPN-6062 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Radim Vansa > > With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls. > Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly. > The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6062?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-6062: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3931 > Remove megamorphic calls when calling next method in interceptor stack > ---------------------------------------------------------------------- > > Key: ISPN-6062 > URL: https://issues.jboss.org/browse/ISPN-6062 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Radim Vansa > > With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls. > Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly. > The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5858) ValueMatcher and AvailabilityMode should have externalizers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5858?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5858: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > ValueMatcher and AvailabilityMode should have externalizers > ----------------------------------------------------------- > > Key: ISPN-5858 > URL: https://issues.jboss.org/browse/ISPN-5858 > Project: Infinispan > Issue Type: Bug > Components: Core > 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.CR1 > > > The default enum serialization is pretty bad, it writes both the enum name and value name as strings. > {{ValueMatcher}} is needed in each write command, so we should optimize it. > {{AvailabilityMode}} doesn't matter that much, except when the coordinator changes, and the new coordinator has to retrieve the status of all the caches on all the nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5857) HotRod client should use the consistent hash in replicated mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5857?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5857: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > HotRod client should use the consistent hash in replicated mode > --------------------------------------------------------------- > > Key: ISPN-5857 > URL: https://issues.jboss.org/browse/ISPN-5857 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.1.Final, 8.1.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: hotrod > Fix For: 8.1.0.Alpha2, 8.1.0.Final > > > The HotRod server assumes that in replicated mode the server accessed by the client doesn't matter, so it doesn't send a consistent hash in the topology updates. > However, since replicated mode is now implemented on top of distributed mode, hitting the primary owner or another node makes a big difference. We should change the server to send the consistent hash for replicated caches as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

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: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > 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)

9 years

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: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > 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)

9 years

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: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > 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)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5859) HotRod server should not use privileged actions for common stuff

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5859?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5859: ----------------------------------------------- Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 1272390|https://bugzilla.redhat.com/show_bug.cgi?id=1272390] from ON_QA to VERIFIED > HotRod server should not use privileged actions for common stuff > ---------------------------------------------------------------- > > Key: ISPN-5859 > URL: https://issues.jboss.org/browse/ISPN-5859 > Project: Infinispan > Issue Type: Bug > Components: 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 HotRod server uses privileged actions to perform operations that are needed for each request, like reading the cache mode to decide what kind (if any) topology update to send to the client. Since privileged actions use thread-locals, we should try to avoid them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6062) Remove megamorphic calls when calling next method in interceptor stack

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6062: --------------------------------- Summary: Remove megamorphic calls when calling next method in interceptor stack Key: ISPN-6062 URL: https://issues.jboss.org/browse/ISPN-6062 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 8.1.0.Final Reporter: Radim Vansa With current acceptor-visitor architecture of interceptor stack, calls to next interceptor use megamorphic interface calls. This is suboptimal as it prohibits the JIT compiler from inlining the calls. Since the interceptor stack is not changed very often, we may adapt the code programmatically to call next interceptor directly. The solution should verify that interceptor stack is inlined as much as possible with 'common' JVM options - increasing -XX:MaxInlineLevel is viable, while we should not request users to mess with -XX:DesiredMethodLimit. Preferably, -XX:FreqInlineSize and -XX:MaxInlineSize should stay at defaults. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6043) TransactionTable should ignore view changes during shutdown

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6043?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6043: ------------------------------- Fix Version/s: 8.1.1.Final > TransactionTable should ignore view changes during shutdown > ----------------------------------------------------------- > > Key: ISPN-6043 > URL: https://issues.jboss.org/browse/ISPN-6043 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Alpha1, 8.1.1.Final > > > During shutdown, {{TransactionTable}} unregisters itself as a view change listener, but it can still receive view change notifications after it stopped the executor service. When that happens, it causes a {{RejectedExecutionException}} that is eventually logged by JGroups: > {noformat} > pbcast.GMS - JGRP000027: failed passing message up > java.lang.RuntimeException: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.util.concurrent.RejectedExecutionException] while invoking method [public void org.infinispan.transaction.TransactionTable.onViewChange(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.transaction.TransactionTable@3d5ab0ba > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:682) > at org.jgroups.JChannel.up(JChannel.java:733) > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029) > at org.jgroups.protocols.RSVP.up(RSVP.java:201) > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) > at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732) > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:922) > at org.jgroups.stack.Protocol.up(Protocol.java:412) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474) > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982) > at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912) > at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618) > at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) > at org.jgroups.protocols.FD.up(FD.java:255) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:288) > at org.jgroups.protocols.Discovery.up(Discovery.java:291) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1572) > at org.jgroups.protocols.TP$MyHandler.run(TP.java:1791) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > Caused by: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.util.concurrent.RejectedExecutionException] while invoking method [public void org.infinispan.transaction.TransactionTable.onViewChange(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent)] on listener instance: org.infinispan.transaction.TransactionTable@3d5ab0ba > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:287) > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:305) > at org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl.notifyViewChange(CacheManagerNotifierImpl.java:88) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport$NotifyViewChange.emitNotification(JGroupsTransport.java:638) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:708) > at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:602) > at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:679) > ... 25 more > Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@1f5986a3 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@2e964769[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1696] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:546) > at java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:646) > at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:641) > at org.infinispan.transaction.TransactionTable.onViewChange(TransactionTable.java:491) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:282) > ... 32 more > {noformat} > The exception is harmless for the stopping cache, the problem is that the following view change listeners are also skipped. We should fix both {{TransactionTable}} to avoid throwing the exception, and {{CacheManagerNotifier}} to ignore any exceptions during view changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2016