July 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6771: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > HotRod Client - TcpTransportFactory - update topology issue with multiple caches > -------------------------------------------------------------------------------- > > Key: ISPN-6771 > URL: https://issues.jboss.org/browse/ISPN-6771 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Environment: Infinispan server 8.2.2.Final > Hot rod client (Java) : 8.2.2.Final > Reporter: Jean-Francois LARTAUD > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha4, 9.0.0.Final, 8.2.4.Final > > > After debugging : > In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache. > * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated. > ** The new servers list is returned only if servers have been added. > ** As this list is not empty, the balancy strategy for the first cache is updated. > * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called > ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();" > ** The associated balancing strategies are not updated. > {code} > public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) { > synchronized (lock) { > Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet); > if (!servers.isEmpty()) { > FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName); > balancer.setServers(servers); > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-3905: -------------------------------------- Fix Version/s: 9.0.0.Alpha4 9.0.0.Final > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Labels: performance > Fix For: 9.0.0.Alpha4, 9.0.0.Final > > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-3905: -------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Labels: performance > Fix For: 9.0.0.Alpha4, 9.0.0.Final > > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6816) Remove unnecessary packages from Embedded Uber Jar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6816?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6816: ---------------------------------- Fix Version/s: 9.0.0.Final 8.2.4.Final > Remove unnecessary packages from Embedded Uber Jar > -------------------------------------------------- > > Key: ISPN-6816 > URL: https://issues.jboss.org/browse/ISPN-6816 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > Fix For: 9.0.0.Final, 8.2.4.Final > > > Things to be removed for sure: > * jboss modules > Things to be checked if can be removed: > * log4j (impl for sure, api - needs to be checked if JBoss Logging won't crash) > * protostream (probably hotrod client needs it) > * protobuf (probably hotrod client needs it) > Things that need to stay: > * hotrod client (remote cache store scenario) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6865) Class loader issue with Log4j in infinispan-embedded

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6865?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-6865. --------------------------------- Resolution: Duplicate Issue > Class loader issue with Log4j in infinispan-embedded > ---------------------------------------------------- > > Key: ISPN-6865 > URL: https://issues.jboss.org/browse/ISPN-6865 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.3.Final > Reporter: Vladimir Dzhuvinov > Priority: Minor > > I would like to bring to your attention an issue with Log4j shadowing in infinispan-embedded. > After a recent upgrade to Log4j 2.6 in our app where we have an infinispan-embedded dependency, we started getting occasional class loader exceptions. A quick inspection with JHades showed that the infinispan-embedded JAR includes a copy of Log4j, introduced by the shadow Maven plugin, but without rewriting the Log4j package names. > Is there any specific reason to shadow Log4j like this? > It also puzzles why we get this exception at all, since Log4j 2.x APIs should not change at all. > {{5-Jul-2016 11:53:45.434 SEVERE [localhost-startStop-1] > org.apache.catalina.core.ContainerBase.addChildInternal > ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: Failed to start component > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/c2id]] > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) > at > org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945) > at > org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1795) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown > Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.NoSuchMethodError: > org.apache.logging.log4j.status.StatusLogger.debug(Ljava/lang/String;Ljava/lang/Object;)V > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:91) > at > org.apache.logging.log4j.core.impl.Log4jContextFactory.<init>(Log4jContextFactory.java:58) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) > at java.lang.reflect.Constructor.newInstance(Unknown Source) > at java.lang.Class.newInstance(Unknown Source) > at org.apache.logging.log4j.LogManager.<clinit>(LogManager.java:93) > at > org.apache.logging.log4j.core.config.Configurator.getFactory(Configurator.java:45) > at > org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:157) > at > org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:168) > at > org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:110) > at > org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5244) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > ... 10 more}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6866) OffHeap Data Container

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-6866: ------------------------------------- Summary: OffHeap Data Container Key: ISPN-6866 URL: https://issues.jboss.org/browse/ISPN-6866 Project: Infinispan Issue Type: Feature Request Components: Core Reporter: Tristan Tarrant Assignee: William Burns Fix For: 9.0.0.Final We want to be able to allocate data off-heap. Requirements / ideas: * data should be stored in Direct ByteBuffers, or easily accessible as such so that integration with other types of I/O (clustering, persistence, server) can be done efficiently * consider both raw byte[] storage (such as that performed by servers) and store as binary * allocator should be pluggable * out-of-the-box implementation should use Netty Buffers * type of allocation (heap or off-heap) should be per-cache * off-heap allocation configuration should be global (per-container) or possibly shared among multiple containers * optional off-heap allocation for keys * ability to monitor both global and per-cache memory usage -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-15) Imports should use double quotes

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-15?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-15: -------------------------------- Description: At the moment both unquoted and quoted file names are accepted, which is not correct. (was: At them moment both unquoted and quoted file names are accepted, which is not correct.) > Imports should use double quotes > -------------------------------- > > Key: IPROTO-15 > URL: https://issues.jboss.org/browse/IPROTO-15 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > At the moment both unquoted and quoted file names are accepted, which is not correct. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-15) Imports should use double quotes

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-15?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned IPROTO-15: ----------------------------------- Assignee: Adrian Nistor > Imports should use double quotes > -------------------------------- > > Key: IPROTO-15 > URL: https://issues.jboss.org/browse/IPROTO-15 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > At them moment both unquoted and quoted file names are accepted, which is not correct. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-15) Imports should use double quotes

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-15?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-15: -------------------------------- Status: Open (was: New) > Imports should use double quotes > -------------------------------- > > Key: IPROTO-15 > URL: https://issues.jboss.org/browse/IPROTO-15 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Adrian Nistor > > At them moment both unquoted and quoted file names are accepted, which is not correct. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-15) Imports should use double quotes

by Adrian Nistor (JIRA)

Adrian Nistor created IPROTO-15: ----------------------------------- Summary: Imports should use double quotes Key: IPROTO-15 URL: https://issues.jboss.org/browse/IPROTO-15 Project: Infinispan ProtoStream Issue Type: Bug Reporter: Adrian Nistor At them moment both unquoted and quoted file names are accepted, which is not correct. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 July 2016