December 2018 - infinispan-issues

[JBoss JIRA] (ISPN-7245) Remove deprecated class org.infinispan.commons.util.Base64

by Adrian Nistor (Jira)

[ https://issues.jboss.org/browse/ISPN-7245?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7245: -------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Final) > Remove deprecated class org.infinispan.commons.util.Base64 > ---------------------------------------------------------- > > Key: ISPN-7245 > URL: https://issues.jboss.org/browse/ISPN-7245 > Project: Infinispan > Issue Type: Task > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9799) Integrate Spring Boot Starter Docs

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9799?page=com.atlassian.jira.plugin.... ] Don Naro reopened ISPN-9799: ---------------------------- > Integrate Spring Boot Starter Docs > ---------------------------------- > > Key: ISPN-9799 > URL: https://issues.jboss.org/browse/ISPN-9799 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Alpha2, 9.4.4.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > > Integrate docs for the Spring Boot starter: https://github.com/infinispan/infinispan-spring-boot/tree/boot-1.5.x > Need to productize for 7.3. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9771) Support for configuration in JSON format

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9771?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9771: ------------------------------------ Status: Open (was: New) > Support for configuration in JSON format > ---------------------------------------- > > Key: ISPN-9771 > URL: https://issues.jboss.org/browse/ISPN-9771 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 10.0.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > To support the cache resource in the v2 endpoint -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9831) IdleStateHandlerProvider's log should be static

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9831?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9831: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > IdleStateHandlerProvider's log should be static > ----------------------------------------------- > > Key: ISPN-9831 > URL: https://issues.jboss.org/browse/ISPN-9831 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > The log field is not static in the IdleStateHandlerProvider. There is no reason it can't be static. This prevents additional allocations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9833) Reorganize to not load jmx classes in client

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9833?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9833: ------------------------------- Status: Open (was: New) > Reorganize to not load jmx classes in client > -------------------------------------------- > > Key: ISPN-9833 > URL: https://issues.jboss.org/browse/ISPN-9833 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > Our client code will load up jmx classes even if it is disabled. We should make sure there are code paths so this doesn't happen. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9833) Reorganize to not load jmx classes in client

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9833?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9833: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6550 > Reorganize to not load jmx classes in client > -------------------------------------------- > > Key: ISPN-9833 > URL: https://issues.jboss.org/browse/ISPN-9833 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > Our client code will load up jmx classes even if it is disabled. We should make sure there are code paths so this doesn't happen. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9833) Reorganize to not load jmx classes in client

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9833?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9833: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Reorganize to not load jmx classes in client > -------------------------------------------- > > Key: ISPN-9833 > URL: https://issues.jboss.org/browse/ISPN-9833 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > Our client code will load up jmx classes even if it is disabled. We should make sure there are code paths so this doesn't happen. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9830) ClassWhiteList loads jboss marshalling despite being optional

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9830?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9830: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ClassWhiteList loads jboss marshalling despite being optional > ------------------------------------------------------------- > > Key: ISPN-9830 > URL: https://issues.jboss.org/browse/ISPN-9830 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.Alpha2, 9.4.4.Final > Reporter: William Burns > Priority: Major > Fix For: 10.0.0.Beta1 > > > The line https://github.com/infinispan/infinispan/blob/master/commons/src/main/jav... loads up a class that loads jboss marshalling. This should use the string instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4585) Prioritize commands in the remote executor

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-4585?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-4585. -------------------------------- Resolution: Won't Do No longer necessary since lock acquisition doesn't block a remote-executor thread. > Prioritize commands in the remote executor > ------------------------------------------ > > Key: ISPN-4585 > URL: https://issues.jboss.org/browse/ISPN-4585 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Priority: Major > > The remote executor currently has an unlimited queue of blocked task, but the underlying executor cannot use a queue. With a queue, we wouldn't need to overflow remote commands to the OOB threads, and the OOB threads would be free to process response messages. > The problem is that {{ThreadPoolExecutor}} executes tasks in the order they are in the queue. If a node has a remote executor thread pool of 100 threads and receives a prepare(tx1, put(k, v1) comand, then 1000 prepare(tx_i, put(k, v_i)) commands, and finally a commit(tx1) command, the commit(tx1) command will block until all but 99 of the the prepare(tx_i, put(k, v_i)) commands have timed out. > I think we could help this by using a {{PriorityBlockingQueue}} for the underlying executor, with commands ordered so that state transfer commands < commit/tx completion notification < prepare/lock. The commit command would still have to wait for one of the prepare commands currently running to time out, but it wouldn't have to wait for all of them. > The current code, without a queue, would fill the remote executor and OOB thread pools, and it would discard the commit message (along with most of the prepare commands). The time it would take to process the commit successfully would depend on the timing of the retransmitted messages. > Another possible improvement would be to keep track of the commands currently being executed, and always keep some threads free for commands with higher priority. But I'm not sure how easy it would be to do that on top of an injected {{ExecutorService}}. > I believe there is also a problem with {{BlockingTaskAwareExecutorServiceImpl.checkForReadyTasks()}} after a topology change. Commands with the new topology id are all unblocked by submitting them to the underlying executor in FIFO order, on a single thread, so {{CallerRunsPolicy}} is not a valid rejection policy here. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1796) Out-of-memory adding a lot of elements in cache with AsyncStore

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-1796?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-1796. -------------------------------- Fix Version/s: 9.2.0.Final Resolution: Done Fixed with ISPN-2293 > Out-of-memory adding a lot of elements in cache with AsyncStore > --------------------------------------------------------------- > > Key: ISPN-1796 > URL: https://issues.jboss.org/browse/ISPN-1796 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores, Transactions > Affects Versions: 5.1.0.CR3 > Environment: We plan to use Infinispan as a large distributed write-behind cache of terabytes of data, with a little fraction cached in RAM, so OOM is real threat for us. > Reporter: Andrew Pushkin > Priority: Major > Labels: executor, threads > Fix For: 9.2.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > OOM occure on peaks of putting objects in cache configured to use AsyncStore. > See Steps to Reproduce. > > Profiling shows that the gc path is through AsyncStore.state field. > The AsyncStore.executor initialized to ThreadPoolExecutor with DiscardPolicy to silently discard tasks if the queue is full, which delays async processing of entries in *state* map, which continues to grow. > Suggested solution. > Instead of DiscardPolicy use customized behavior, which is to estimate accumulated state size and (probably comparing it with modificationQueueSize) decide to discard or to block until it is processed. > The downside of suggested solution is the necessity to lock to estimate state size every time the task is rejected. Possibly it can be alleviated by increasing workingQueue size, so that it survive peaks without rejection. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 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 December 2018