September 2018 - infinispan-issues

[JBoss JIRA] (ISPN-2793) REST Server WAR default config

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2793?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2793. --------------------------------- Resolution: Out of Date > REST Server WAR default config > ------------------------------ > > Key: ISPN-2793 > URL: https://issues.jboss.org/browse/ISPN-2793 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.2.0.Final > Reporter: Michal Linhard > Priority: Minor > > REST Server war file comes with this web.xml > {code} >  > <init-param> > <param-name>infinispan.config</param-name> > <param-value>config-samples/sample.xml</param-value> > </init-param> > {code} > that depend's on certain file to exist, otherwise the deployment will throw an exception: > {code} > 09:20:14,148 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-2) Servlet /infinispan threw load() exception: java.io.FileNotFoundException: config-samples/sample.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.6.0_37] > at java.io.FileInputStream.<init>(FileInputStream.java:120) [rt.jar:1.6.0_37] > at java.io.FileInputStream.<init>(FileInputStream.java:79) [rt.jar:1.6.0_37] > at org.infinispan.util.AbstractFileLookup.lookupFileStrict(AbstractFileLookup.java:83) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:326) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:313) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT] > at org.infinispan.rest.StartupListener.init(StartupListener.scala:59) [classes:] > at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:] > at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37] > {code} > What about commenting this out, so that default config is used. > I'll do the pull if you agree.. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2679) Security needs to be implemented for memcache interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2679?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2679. --------------------------------- Resolution: Won't Do > Security needs to be implemented for memcache interface > ------------------------------------------------------- > > Key: ISPN-2679 > URL: https://issues.jboss.org/browse/ISPN-2679 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Memcached, Server > Reporter: Joel Tosi > Labels: security > > Breakdown from ISPN-143 - https://issues.jboss.org/browse/ISPN-143 > We need to have security implemented in the memcache interface -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2709) Lib dir in distribution archive does not contain the proper versions for some dependencies

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2709?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2709. --------------------------------- Resolution: Out of Date > Lib dir in distribution archive does not contain the proper versions for some dependencies > ------------------------------------------------------------------------------------------- > > Key: ISPN-2709 > URL: https://issues.jboss.org/browse/ISPN-2709 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 5.2.0.CR1 > Reporter: Adrian Nistor > Attachments: actual.txt, should_be.txt > > > Not all the jars referenced by runtime-classpath.txt files of modules are actually present in the lib dir. In some cases the jar is present but not the needed version. Some of the jars are there but are not actually used. > It all happens because the set of dependencies for runtime-classpath.txt is computed for each individual module while the lib dir in the distro is created by assembly plugin after 'merging' the dependencies of all modules which means that only the highest version will be included. Also, maven dependency plugin is known to miss some dependencies. > To avoid the version problem we could define globally a single version for each of these dependencies in parent pom dependencyManagement and also explicitly add the dependency in the respective modules. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2710) Huge amount of OOB threads during performance test

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2710?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2710. --------------------------------- Resolution: Out of Date > Huge amount of OOB threads during performance test > -------------------------------------------------- > > Key: ISPN-2710 > URL: https://issues.jboss.org/browse/ISPN-2710 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.2.0.CR1 > Reporter: Robert Stupp > Priority: Minor > > While running our performance test (as described in ISPN-2240), two of the four servers are running at 80 to 100% CPU - while the others just run at 10%. > Before that phenomenom a huge amount (several 100s) of threads has been created (all called {{OOB-xxxx}}. > The performance test just reads cached data - there was no cache put operation at that time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2391) Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters)

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2391?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2391. --------------------------------- Resolution: Out of Date > Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters) > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2391 > URL: https://issues.jboss.org/browse/ISPN-2391 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 5.2.0.Beta1 > Reporter: Vladimir Blagojevic > Priority: Minor > > During review of https://github.com/infinispan/infinispan/pull/1369 Manik observed inconsistency in wording of IllegalStateException thrown from ReplicableCommand#setParameters(int commandId, Object[] parameters). However, upon further review it was noted that all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters) are inconsistent potentially confusing sys admins and support engineers. We should create a single consistent messages for all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2376. --------------------------------- Resolution: Out of Date > KeyAffinityServiceImpl.getKeyForAddress() can loop forever when DefaultConsistentHash has numSegments < numNodes > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2376 > URL: https://issues.jboss.org/browse/ISPN-2376 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0.Beta1 > Reporter: Scott Marlow > Priority: Minor > > I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet. We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning). > We have two nodes running in the AS cluster, node-0/web and node-1/web. > In my recent test run, I stopped the test after it was stuck for a while. Below is some of the instrumented logging output. > {quote} > KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web] > . > . > . > KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web > {quote} > We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero). > Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}). > I'm still collecting information and want to get a little more. > Let me know if there is anything that you would like to see. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2334) Distributed mode and single shared cache loader - preload and state transfer

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2334?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2334. --------------------------------- Resolution: Out of Date > Distributed mode and single shared cache loader - preload and state transfer > ---------------------------------------------------------------------------- > > Key: ISPN-2334 > URL: https://issues.jboss.org/browse/ISPN-2334 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, State Transfer > Affects Versions: 5.1.5.FINAL > Reporter: Fernando Wasylyszyn > Priority: Minor > > When you have a cluster in Infinispan, configured as Distributed and with a single and shared cache loader by all members, the preload option should work making each node loading the entries that correspond to it, not all of them, which is the current behaviour. > Also, with this configuration, the "state transfer" could be configured to make each node retrieve the "new entries" that should keep after a topology change directly from the cache store, instead of the transfer of entries through the network. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2308) Allow SpringCache to be configured to use asynchronous operations

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2308?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2308. --------------------------------- Resolution: Done > Allow SpringCache to be configured to use asynchronous operations > ----------------------------------------------------------------- > > Key: ISPN-2308 > URL: https://issues.jboss.org/browse/ISPN-2308 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Reporter: Mircea Markus > > There is a pull request[1] pending for quite some time(3 months) for this. As there's no activity I'm creating a JIRA and closing the pull request for now. > [1] https://github.com/infinispan/infinispan/pull/1097 > ----------------- > In testing with a cache that was configured to use asynchronous replication, I was seeing some exceptions in my logs about timeout waiting for a lock on a key when doing a put. (It was not frequent - under heavy load testing it was only on a very small percentage of calls to my service) > Since I was using the @Cacheable annotation to do the caching around those method calls - there was no way for me to catch the CacheExceptions that were thrown. This means that these exceptions were resulting in my services returning 500 errors to the client. > Poking around, it seems that using the putAsync method would make the put methods return immediately and any exception would not be in the same thread so it wouldn't matter. > For my use, a put that fails is fine - spring will just put it in the next time if there is no value in the cache. > This pull request creates a configuration parameter on the EmbeddedCacheManagerFactory and EmbeddedRemoteCacheManagerFactory for "useAsynchronousCacheOperations" which, when set to true, will use a SpringAsynchrnousCache to wrap the native cache instead of the default SpringCache. > I added unit tests around this and updated other tests. > In my own load testing environment, I'm no longer seeing the errors related to cache put key lock timeouts and the execution time for my methods has improved in cases when it would have otherwise been blocking waiting for a put. > (this is a new pull request against the 5.1.x branch - although the changes also apply cleanly to the 5.2 branch as that's where I first created them) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2302) New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2302?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2302. --------------------------------- Resolution: Out of Date > New JdbcCacheStoreConfigurationBuilder should support existing ConnectionFactoryConfig > -------------------------------------------------------------------------------------- > > Key: ISPN-2302 > URL: https://issues.jboss.org/browse/ISPN-2302 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.2.0.Alpha3 > Reporter: Thomas Fromm > > I've the situation the I need to reuse existing ConnectionFactoryConfigs. > Maybe implement ConnectionFactoryConfigurationBuilder with method read(ConnectionFactoryConfig template). Then extend JdbcCacheStoreConfigurationBuilder and add connectionFactory()? > I need it at least for the deprecated config migration of the ISPN test cases... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2236) Test JDBC CacheStore with MSSQL, Informix, DB2 and PGSQL

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2236?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-2236. ----------------------------------- Resolution: Done Compat matrix with multiple databases is handled by QE > Test JDBC CacheStore with MSSQL, Informix, DB2 and PGSQL > -------------------------------------------------------- > > Key: ISPN-2236 > URL: https://issues.jboss.org/browse/ISPN-2236 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Thomas Fromm > Assignee: Thomas Fromm > > Needs to be tested. > I expect problems like I got when I started using ISPN with Oracle. > Consider Maven profile for creating automated tests of them with internal JBoss Test infrastructure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 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 September 2018