July 2016 - infinispan-issues - Jboss List Archives

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

8 years, 5 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)

8 years, 5 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)

8 years, 5 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)

8 years, 5 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)

8 years, 5 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)

8 years, 5 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)

8 years, 5 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)

8 years, 5 months

1
0
0 / 0

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

by Vladimir Dzhuvinov (JIRA)

Vladimir Dzhuvinov created ISPN-6865: ---------------------------------------- Summary: 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)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6864) Add support for CORS headers to REST server

by Vladimir Dzhuvinov (JIRA)

[ https://issues.jboss.org/browse/ISPN-6864?page=com.atlassian.jira.plugin.... ] Vladimir Dzhuvinov commented on ISPN-6864: ------------------------------------------ I suppose CORS support could be retrofitted by adding a filter to handle the Access-Control-* headers, however I cannot suggest how to approach this with WildFly and the way the Infinispan server is packaged. I have implemented a servlet filter for CORS which may be configured from web.xml, an properties file or from system properties. http://software.dzhuvinov.com/cors-filter.html > Add support for CORS headers to REST server > ------------------------------------------- > > Key: ISPN-6864 > URL: https://issues.jboss.org/browse/ISPN-6864 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: James Falkner > Priority: Minor > > Currently it is not possible to enable browser-based applications to call infinispan REST APIs due to the lack of [CORS|https://en.wikipedia.org/wiki/Cross-origin_resource_sharing] headers in the responses, and there is no way to alter the underlying web server to include these. > This request asks that CORS headers be optionally returned in REST requests, and be configurable by admins. Specifically, the following headers: > * Access-Control-Allow-Origin > * Access-Control-Allow-Credentials > * Access-Control-Expose-Headers > * Access-Control-Max-Age > * Access-Control-Allow-Methods > * Access-Control-Allow-Headers > This would enable browser-based apps to function when working across domains. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2016