[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
[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
[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
[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
[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
[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