November 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8397) Tune eviction and memory settings for Caching Service

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8397?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-8397: -------------------------------------- Git Pull Request: https://github.com/jboss-container-images/jboss-dataservices-image/pull/19, https://github.com/jboss-container-images/jboss-dataservices-image/pull/23, https://github.com/jboss-container-images/jboss-dataservices-image/pull/25 (was: https://github.com/jboss-container-images/jboss-dataservices-image/pull/19, https://github.com/jboss-container-images/jboss-dataservices-image/pull/23) > Tune eviction and memory settings for Caching Service > ----------------------------------------------------- > > Key: ISPN-8397 > URL: https://issues.jboss.org/browse/ISPN-8397 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > We need to prevent going out of memory. This requires tuning memory as well as eviction settings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8069) Clustered Locks Embedded Mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8069?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8069: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.0.Beta1 9.2.0.Final Resolution: Done > Clustered Locks Embedded Mode > ----------------------------- > > Key: ISPN-8069 > URL: https://issues.jboss.org/browse/ISPN-8069 > Project: Infinispan > Issue Type: Feature Request > Reporter: Katia Aresti > Assignee: Katia Aresti > Fix For: 9.2.0.Beta1, 9.2.0.Final > > > This issue will only supply an implementation for a Node Level Ownership and Non rentrant lock > h2. ClusteredLockManager and configuration > {code:java} > package org.infinispan.lock.api; > public class ClusteredLockManager { > boolean defineLock(String name); > ClusteredLock get(String name); > boolean isDefined(String name); > CompletableFuture<Boolean> remove(String name); > CompletableFuture<Void> reset(String name); > } > public class ClusteredLockConfiguration { > private final OwnershipLevel ownershipLevel; // default NODE > private final boolean rentrant; // default false > } > public enum OwnershipLevel { > NODE, // Node can lock if it owns the lock without blocking, only the owner node can unlock > INSTANCE, // Instance can lock multiple times if it owns the lock without blocking, only the owner instance can unlock > } > {code} > h4. ClusteredLock defineLock(String name, LockConfiguration configuration) > Defines a lock with the specific name and LockConfiguration. It does not overwrite existing configurations. > Returns true if successfully defined or false if the lock is already defined or any other failure. If silentFailover is false, then InfinispanLockException will be raised. > h4. ClusteredLock get(String name) > Get’s a InfinipanLock by it’s name and throws InfinispanLockException if the lock is not not defined. User must call defineLock before this method. > h4. boolean isDefined(String name) > True if the lock exists, false if it doesn’t > h4. CompletableFuture<Boolean> remove(String name) > Removes a Lock from the system. Returns true when it was removed, false when the lock does not exist. If any other Runtime problems appear, InfinispanLockException will be raised withe the reason. As Locks are not removed automatically, so this has to be done programatically when the Lock is no longer needed. Otherwise, OutOfMemoryException could happen. > Remove must be executed when the lock is locked, because running that without exclusive access should result in an exception. Internally, the implementation should contain generation number so that attempts to acquire a lock of a removed generation will result it exceptions in the other callers, too. > h4. CompletableFuture<Void> reset(String name) > Resets the lock to its initial state. If any parties are currently waiting at the lock, they will return with failure on the CompletableFuture > h2. ClusteredLock > > When a cluster node holding a Lock dies, this lock is released and available for the others. > {code:java} > public interface ClusteredLock { > CompletableFuture<Void> lock(); > CompletableFuture<Boolean> tryLock(); > CompletableFuture<Boolean> tryLock(long time, TimeUnit unit); > CompletableFuture<Void> unlock(); > } > {code} > h4. CompletableFuture<Void> lock(); > CompletableFuture is completed successfully when the lock is acquired When a lock is aquired by a client, it will be automatically released after the maxLeaseTime specified. RenewalLeaseTime is the interval time is the time a client can aquire a lock consecutively User should set the timeouts to non-positive value The initial embedded implementation does not have to support positive values > h4. CompletableFuture<Boolean> tryLock(); > Acquires the lock only if it is free at the time of invocation. Acquires the lock if it is available and returns with the value true. If the lock is not available then this method with the value false. > h4. CompletableFuture<Boolean> tryLock(long time, TimeUnit unit); > Acquires the lock if it is free within the given waiting time. If the lock is available this method returns with the value true. > Parameters: time - the maximum time to wait for the lock unit - the time unit of the time argument Returns: true if the lock was acquired and false if the waiting time elapsed before the lock was acquired > CompletableFuture fails with InfinispanLockException in case of error (InterruptedException, or any other non checked exceptions) > h4. CompletableFuture<Boolean> unlock(); > If the lock is rentrant (Node or Instance), only the instance or node holding the lock will be able to unlock, otherwise, anybody can unlock and it will behave as a Semaphore with one permit. True answer will say that the operation was succesul and the lock has been released, false the lock has not been relased -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8235) Null values are counted in remote queries with aggregations

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-8235?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-8235: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5439, https://github.com/infinispan/infinispan/pull/5508, https://github.com/infinispan/infinispan/pull/5511, https://github.com/infinispan/infinispan/pull/5579, https://github.com/infinispan/infinispan/pull/5582 (was: https://github.com/infinispan/infinispan/pull/5439, https://github.com/infinispan/infinispan/pull/5508, https://github.com/infinispan/infinispan/pull/5511, https://github.com/infinispan/infinispan/pull/5579) > Null values are counted in remote queries with aggregations > ----------------------------------------------------------- > > Key: ISPN-8235 > URL: https://issues.jboss.org/browse/ISPN-8235 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 9.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.1.2.Final, 9.2.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-8396: ------------------------------------------- This all sounds good to me. BTW, I think we could emit a warning message if {{MEMORY-EXCEPTION}} is used with transactional caches. //cc [~pruivo] > Add interceptor preventing going out of memory > ---------------------------------------------- > > Key: ISPN-8396 > URL: https://issues.jboss.org/browse/ISPN-8396 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations, Core > Reporter: Sebastian Łaskawiec > Assignee: William Burns > > We need an interceptor which will calculate the amount of required memory for PUT and report an error if that put will cause going out of memory. > Note that this is strictly connected to eviction mechanism (we might want to evict some entries on write) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8422) Investigate removal of hashCode from memory block and rely solely on equals

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8422?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-8422: ------------------------------------ [~william.burns] good point, {{peekOrGet()}} could check the hash-code of an off-heap entry without creating an {{InternalCacheEntry}}, which would speed things up when there are many collisions. > Investigate removal of hashCode from memory block and rely solely on equals > --------------------------------------------------------------------------- > > Key: ISPN-8422 > URL: https://issues.jboss.org/browse/ISPN-8422 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > We could remove the hashCode 4 bytes taking up space in the allocated memory block. Currently this is only used for eviction, maybe instead we could write a VInt that says which offset of locks to use. In majority of cases <= 64 cores this will result in saving 3 bytes per entry. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8512) Upgrade to Netty 4.1.16.Final

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8512?page=com.atlassian.jira.plugin.... ] Ryan Emerson commented on ISPN-8512: ------------------------------------ Upgrading to Netty 4.1.10 or higher results in consistent failure of org.infinispan.server.hotrod.HotRodSniFunctionalTest.testServerWithNotMatchingDefaultAndClientWithSNI {code} java.lang.AssertionError: expected [false] but found [true] at org.infinispan.server.hotrod.HotRodSniFunctionalTest.testServerWithNotMatchingDefaultAndClientWithSNI(HotRodSniFunctionalTest.java:114) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ... Removed 20 stack frames {code} > Upgrade to Netty 4.1.16.Final > ----------------------------- > > Key: ISPN-8512 > URL: https://issues.jboss.org/browse/ISPN-8512 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Tristan Tarrant > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6558) Typo in export package of infinispan-persistence-soft-index OSGI module

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6558?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6558: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.4.Final 8.1.10.Final 8.2.9.Final 9.2.0.Beta1 9.1.3.Final Assignee: Dan Berindei Resolution: Done > Typo in export package of infinispan-persistence-soft-index OSGI module > ----------------------------------------------------------------------- > > Key: ISPN-6558 > URL: https://issues.jboss.org/browse/ISPN-6558 > Project: Infinispan > Issue Type: Bug > Components: Build process, Loaders and Stores > Affects Versions: 7.2.5.Final, 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Andreas Pabst > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.4.Final, 8.1.10.Final, 8.2.9.Final, 9.2.0.Beta1, 9.1.3.Final > > > {code:xml} > <Export-Package> > ${project.groupId}.persistence.sfis.* > </Export-Package> > {code} > I assume it should be *sifs*, not sfis. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6558) Typo in export package of infinispan-persistence-soft-index OSGI module

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6558?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6558: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5581 > Typo in export package of infinispan-persistence-soft-index OSGI module > ----------------------------------------------------------------------- > > Key: ISPN-6558 > URL: https://issues.jboss.org/browse/ISPN-6558 > Project: Infinispan > Issue Type: Bug > Components: Build process, Loaders and Stores > Affects Versions: 7.2.5.Final, 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Andreas Pabst > Priority: Minor > > {code:xml} > <Export-Package> > ${project.groupId}.persistence.sfis.* > </Export-Package> > {code} > I assume it should be *sifs*, not sfis. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6558) Typo in export package of infinispan-persistence-soft-index OSGI module

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6558?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6558: ------------------------------- Status: Open (was: New) > Typo in export package of infinispan-persistence-soft-index OSGI module > ----------------------------------------------------------------------- > > Key: ISPN-6558 > URL: https://issues.jboss.org/browse/ISPN-6558 > Project: Infinispan > Issue Type: Bug > Components: Build process, Loaders and Stores > Affects Versions: 7.2.5.Final, 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Andreas Pabst > Priority: Minor > > {code:xml} > <Export-Package> > ${project.groupId}.persistence.sfis.* > </Export-Package> > {code} > I assume it should be *sifs*, not sfis. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2489) infinispan-core stores resources in default package, preventing OSGI export

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2489?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-2489. -------------------------------- Resolution: Done I believe this was fixed by ISPN-3850, using an exact classloader. > infinispan-core stores resources in default package, preventing OSGI export > --------------------------------------------------------------------------- > > Key: ISPN-2489 > URL: https://issues.jboss.org/browse/ISPN-2489 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.6.FINAL, 5.2.0.Beta3 > Reporter: Vitalii Tymchyshyn > > Currently infinispan stores resources (e.g. infinispan-core-component-metadata.dat) in the default package. This makes this resources private to infinispan-core OSGI bundle as default package can't be exported > So, first of all it does not start by default when cache manager is created from another bundle. If configuration is created explicitly passing infinispan-core classloader, it can start, but no additional components can be used (e.g. loaders from another bundles). > I can see next possible options to handle this: > 1) Move resources to the package > 2) Use multiple classloaders to read resources (as it's done for classes) > 3) Use exact classloader, e.g. use fixed infinispan-core classloader to get infinispan-core-component-metadata.dat. Dunno if this would work for all resources, like jgroups configuration files. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017