October 2020 - infinispan-issues - Jboss List Archives

[Red Hat JIRA] (ISPN-12413) Clustered listeners for replicated caches do not receive events on zero capacity nodes

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12413?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-12413: -------------------------------- Status: Open (was: New) > Clustered listeners for replicated caches do not receive events on zero capacity nodes > -------------------------------------------------------------------------------------- > > Key: ISPN-12413 > URL: https://issues.redhat.com/browse/ISPN-12413 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 12.0.0.Dev04 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Dev05 > > > ISPN-12221 added zero capacity factor support for replicated caches, so that nodes with {{zeroCapacityNode(true)}} do not store any entries. > This broke clustered listeners, which only install a local listener on the primary owners if the cache is distributed or scattered. > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[Red Hat JIRA] (ISPN-8241) Refactor RocksDB clearThreshold

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-8241?page=com.atlassian.jira.plugin... ] Dan Berindei commented on ISPN-8241: ------------------------------------ [~dlovison] I think we can remove {{NonSegmentedRocksDBHandler}} immediately, if we put the segment as the start of the key in {{SegmentedRocksDBHandler}}. The only advantage of {{NonSegmentedRocksDBHandler}} that I know of is that it needs fewer open files, but that will go away once {{SegmentedRocksDBHandler}} doesn't need one column family per segment any more. Even now, I believe the implementation of {{NonSegmentedRocksDBHandler#clear(IntSet)}} uses {{clearThreshold}} wrong. It should never destroy the database when the {{segments}} parameter is not {{null}}, otherwise it risks destroying a database that still holds data. Finally, I'd argue that since {{clearThreshold()}} is not documented except as "Cache store cache clear threshold." in the XSD, it's already kind-of-deprecated. When we finally deprecate it officially and remove references to it in the code, nobody will notice. > Refactor RocksDB clearThreshold > ------------------------------- > > Key: ISPN-8241 > URL: https://issues.redhat.com/browse/ISPN-8241 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Diego Lovison > Priority: Major > > Currently the RocksDB store utilises a "clearThreshold" to try to delete entries individually before deleting and re-initiating the database. We should deprecate this threshold and always delete/reinit the database. > Currently when deleting the database, we utilise Util.recursiveFileRemove which does not confirm that the file has actually been deleted. Instead, we should provide a nio based implementation instead, similar to the one stated [here|https://stackoverflow.com/questions/779519/delete-directories-recurs...]. This has the advantage that an IOException is thrown by java.nio.file.Files::delete -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10216) Implement bloom filter based near cache invalidations

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-10216?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-10216: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8767 > Implement bloom filter based near cache invalidations > ----------------------------------------------------- > > Key: ISPN-10216 > URL: https://issues.redhat.com/browse/ISPN-10216 > Project: Infinispan > Issue Type: Sub-task > Components: Hot Rod, Listeners > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > Currently our near cache invalidation messages contain every remove/modify/expired event. It would be preferable to only send known invalidation messages to the client using some sort of bloom filter based approach. This should help reduce the number of total messages and allow for write clients to operate more efficiently. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8241) Refactor RocksDB clearThreshold

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/ISPN-8241?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-8241: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8766 > Refactor RocksDB clearThreshold > ------------------------------- > > Key: ISPN-8241 > URL: https://issues.redhat.com/browse/ISPN-8241 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Diego Lovison > Priority: Major > > Currently the RocksDB store utilises a "clearThreshold" to try to delete entries individually before deleting and re-initiating the database. We should deprecate this threshold and always delete/reinit the database. > Currently when deleting the database, we utilise Util.recursiveFileRemove which does not confirm that the file has actually been deleted. Instead, we should provide a nio based implementation instead, similar to the one stated [here|https://stackoverflow.com/questions/779519/delete-directories-recurs...]. This has the advantage that an IOException is thrown by java.nio.file.Files::delete -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8241) Refactor RocksDB clearThreshold

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/ISPN-8241?page=com.atlassian.jira.plugin... ] Diego Lovison commented on ISPN-8241: ------------------------------------- Notes: * We can't deprecate `clearThreshold` because it is used for `NonSegmentedRocksDBHandler`. The segment info is part of the key * This PR also fixes a critical issue when `segments != null`. The `clearThreshold` technique was not used. When we remove `NonSegmentedRocksDBHandler` we will be able to deprecate|remove `clearThreshold` > Refactor RocksDB clearThreshold > ------------------------------- > > Key: ISPN-8241 > URL: https://issues.redhat.com/browse/ISPN-8241 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Diego Lovison > Priority: Major > > Currently the RocksDB store utilises a "clearThreshold" to try to delete entries individually before deleting and re-initiating the database. We should deprecate this threshold and always delete/reinit the database. > Currently when deleting the database, we utilise Util.recursiveFileRemove which does not confirm that the file has actually been deleted. Instead, we should provide a nio based implementation instead, similar to the one stated [here|https://stackoverflow.com/questions/779519/delete-directories-recurs...]. This has the advantage that an IOException is thrown by java.nio.file.Files::delete -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-165) Maven compiler plugin 3.8.1 and Protostream - Marshaller java files not compiled into class files

by Rostislav Svoboda (Jira)

Rostislav Svoboda created IPROTO-165: ---------------------------------------- Summary: Maven compiler plugin 3.8.1 and Protostream - Marshaller java files not compiled into class files Key: IPROTO-165 URL: https://issues.redhat.com/browse/IPROTO-165 Project: Infinispan ProtoStream Issue Type: Bug Affects Versions: 4.3.3.Final Reporter: Rostislav Svoboda Assignee: Nistor Adrian Fix For: 4.4.0.Alpha1, 4.3.4.Final Coming from a Quarkus issue, the maven compiler plugin in version 3.8.1 seems not working properly with classes compilation and generation Check the Quarkus issue. [https://github.com/quarkusio/quarkus/issues/9980] This might be a library problem or a maven problem -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12415) Force JSoup version to 1.9.2

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12415?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12415: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8764, https://github.com/infinispan/infinispan/pull/8765 > Force JSoup version to 1.9.2 > ---------------------------- > > Key: ISPN-12415 > URL: https://issues.redhat.com/browse/ISPN-12415 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 12.0.0.Dev05, 11.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12415) Force JSoup version to 1.9.2

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12415?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12415: ------------------------------- Status: Open (was: New) > Force JSoup version to 1.9.2 > ---------------------------- > > Key: ISPN-12415 > URL: https://issues.redhat.com/browse/ISPN-12415 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 12.0.0.Dev05, 11.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12415) Force JSoup version to 1.9.2

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-12415: ---------------------------------- Summary: Force JSoup version to 1.9.2 Key: ISPN-12415 URL: https://issues.redhat.com/browse/ISPN-12415 Project: Infinispan Issue Type: Component Upgrade Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 12.0.0.Dev05, 11.0.5.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12414) Upgrade TestNG to 7.3.0

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12414?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12414: ------------------------------- Fix Version/s: 12.0.0.Dev05 11.0.5.Final > Upgrade TestNG to 7.3.0 > ----------------------- > > Key: ISPN-12414 > URL: https://issues.redhat.com/browse/ISPN-12414 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 12.0.0.Dev05, 11.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2020