September 2019 - infinispan-issues

[JBoss JIRA] (ISPN-10645) Configured eviction bases on COUNT will unexpected start eviction to early and might evict until the cache is empty

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10645?page=com.atlassian.jira.plugin... ] Will Burns commented on ISPN-10645: ----------------------------------- This is expected behavior. The 59 is due to entries expiring after 60 seconds, which means with an insertion rate of 1 per second will only have 59-60 entries in the cache at a time. The cache dropping to a size of 2 is because of the access pattern and the fact that the expiration reaper is disabled. Caffeine uses the TinyLFU algorithm for its eviction. Effectively what happened is that it is Caffeine uses an eden space of 2 that store the most recently added entries. Once this fills up it will add that entry into the main space. Due to the access pattern it has determined the new entry should be immediately evicted. This causes the cache to have 2 "new" entries that aren't expired an 118 that are expired and aren't being evicted. If you enable the reaper it will clean these out sooner and never get to that point. > Configured eviction bases on COUNT will unexpected start eviction to early and might evict until the cache is empty > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10645 > URL: https://issues.jboss.org/browse/ISPN-10645 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.CR2 > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > If a cache is populated and configured with eviction and maybe expiration the eviction will start earlier than expected and the size count will go down to more or less 0. > Assume the cache is configured like this > <distributed-cache name="ExpirationCache"> > <memory> > <binary eviction="COUNT" size="120"/> > </memory> > <expiration lifespan="60000" interval="-1"/> > </distributed-cache> > The client is simple and add a new entry every second to keep the monitoring simple > minute 1 - entries are added up to ~59 without eviction > minute 2 - entries are added but the cache.size() is still 59 > CLI check attribute number_of_entries and evictions for the cache > shows the same size and no eviction > minute 3 - continue adding, cache.size()==59 but > CLI shows the same size and increasing evictions > minute 4 - still adding but size() decrease as well as CLI n-o-e and evictions grow > The fact is that having less than 120 entries in the cache is unexpected as well as remove more entries after a time. > The issue remain for > <off-heap> and <object> with object count. > as well as without exiration element or configured with interval - here the entries are expiring but eviction will have effects as well and drop the cache content unexpected. > So it seems not releated to expiration at all -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10650?page=com.atlassian.jira.plugin... ] Pedro Ruivo commented on ISPN-10650: ------------------------------------ 10.x (master) PR integrated! > Expiration should not be replicated cross site > ---------------------------------------------- > > Key: ISPN-10650 > URL: https://issues.jboss.org/browse/ISPN-10650 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Expiration > Affects Versions: 9.4.16.Final, 10.0.0.CR2 > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.CR3, 9.4.17.Final > > > There is no reason currently to replicate expiration commands across site. > Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks. > However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10664) Expiration should not be replicated cross site

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-10664: ---------------------------------- Summary: Expiration should not be replicated cross site Key: ISPN-10664 URL: https://issues.jboss.org/browse/ISPN-10664 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication, Expiration Affects Versions: 9.4.16.Final, 10.0.0.CR2 Reporter: Will Burns Assignee: Will Burns Fix For: 10.0.0.CR3, 9.4.17.Final There is no reason currently to replicate expiration commands across site. Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks. However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10663?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10663: --------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7357 > TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-10663 > URL: https://issues.jboss.org/browse/ISPN-10663 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.CR3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10662) Metrict for evictions does not count entries but memory bytes if <off-heap> is used

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-10662: --------------------------------------- Summary: Metrict for evictions does not count entries but memory bytes if <off-heap> is used Key: ISPN-10662 URL: https://issues.jboss.org/browse/ISPN-10662 Project: Infinispan Issue Type: Bug Reporter: Wolf-Dieter Fink Assignee: Will Burns Configuration with off-heap <cache-container name="clustered" default-cache="ExpirationCache" statistics="true"> <transport lock-timeout="60000"/> <global-state/> <distributed-cache name="ExpirationCache"> <memory> <off-heap eviction="COUNT" size="120"/> </memory> </distributed-cache> Any eviction will increase the counter evictions not by 1 for entry but by a value which seems the amount of bytes. <object> or <binary> configuration work as expected -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Nistor Adrian (Jira)

Nistor Adrian created ISPN-10663: ------------------------------------ Summary: TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds Key: ISPN-10663 URL: https://issues.jboss.org/browse/ISPN-10663 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 10.0.0.CR2 Reporter: Nistor Adrian Assignee: Nistor Adrian Fix For: 10.0.0.CR3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10663?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10663: --------------------------------- Status: Open (was: New) > TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-10663 > URL: https://issues.jboss.org/browse/ISPN-10663 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.CR3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10663?page=com.atlassian.jira.plugin... ] Work on ISPN-10663 started by Nistor Adrian. -------------------------------------------- > TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-10663 > URL: https://issues.jboss.org/browse/ISPN-10663 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.CR3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10661) Avoid blocking IO threads on CacheInputStream

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10661?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10661: ------------------------------------- Description: As part of ISPN-10376, the REST server is serving keys using Netty's {{ChunkedWriteHandler}} that will convert a InputStream into chunks and will write it to the client. As the source of the InputStream is a CacheStream, that can block, it's desirable to do the retrieval of the cache data in a separate thread, using the suspend and resume capabilities of the {{ChunkedWriteHandler}} when data is available [https://netty.io/4.0/api/io/netty/handler/stream/ChunkedWriteHandler.html...] was: As part of ISPN-10376, the REST server is serving keys using Netty's {{ChunkedWriteHandler}} that will convert a InputStream into chunks and will write it to the client. As the source of the InputStream is a CacheStream, that can block, it's desirable to do the retrieval of the cache data in a separate thread, using the suspend and resume capabilities of the {{ChunkedWriteHandler}} when data is available https://netty.io/4.0/api/io/netty/handler/strea/ChunkedWriteHandler.html#... > Avoid blocking IO threads on CacheInputStream > --------------------------------------------- > > Key: ISPN-10661 > URL: https://issues.jboss.org/browse/ISPN-10661 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > As part of ISPN-10376, the REST server is serving keys using Netty's {{ChunkedWriteHandler}} that will convert a InputStream into chunks and will write it to the client. > As the source of the InputStream is a CacheStream, that can block, it's desirable to do the retrieval of the cache data in a separate thread, using the suspend and resume capabilities of the {{ChunkedWriteHandler}} when data is available > [https://netty.io/4.0/api/io/netty/handler/stream/ChunkedWriteHandler.html...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10661) Avoid blocking on CacheInputStream

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-10661: ---------------------------------------- Summary: Avoid blocking on CacheInputStream Key: ISPN-10661 URL: https://issues.jboss.org/browse/ISPN-10661 Project: Infinispan Issue Type: Enhancement Components: REST Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes As part of ISPN-10376, the REST server is serving keys using Netty's {{ChunkedWriteHandler}} that will convert a InputStream into chunks and will write it to the client. As the source of the InputStream is a CacheStream, that can block, it's desirable to do the retrieval of the cache data in a separate thread, using the suspend and resume capabilities of the {{ChunkedWriteHandler}} when data is available https://netty.io/4.0/api/io/netty/handler/strea/ChunkedWriteHandler.html#... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 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 2019