November 2019 - infinispan-issues

[JBoss JIRA] (ISPN-10963) Remove blocking queue from RocksDBStore

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10963?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-10963: --------------------------------- Status: Open (was: New) > Remove blocking queue from RocksDBStore > --------------------------------------- > > Key: ISPN-10963 > URL: https://issues.jboss.org/browse/ISPN-10963 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. > By default it will be running each minute and the client will totally block. > {code:java} > cacheManager.defineConfiguration("weather", new ConfigurationBuilder() > .persistence() > .addStore(RocksDBStoreConfigurationBuilder.class) > .location("target/data") > .expiredLocation("target/expired") > .expiration().lifespan(5, TimeUnit.SECONDS) > .build()); > cache = cacheManager.getCache("weather"); > int max = 10001; > for (int i=0; i<max; i++) { > cache.put(UUID.randomUUID().toString(), UUID.randomUUID().toString()); > } > {code} > The test took 60478ms. > 9999 = 1773 ms > 10000 = 1797 ms > Removing the queue and writing directly to RocksDB will be faster than the current code -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10963) Remove blocking queue from RocksDBStore

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10963?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-10963: --------------------------------- Status: Pull Request Sent (was: Open) > Remove blocking queue from RocksDBStore > --------------------------------------- > > Key: ISPN-10963 > URL: https://issues.jboss.org/browse/ISPN-10963 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. > By default it will be running each minute and the client will totally block. > {code:java} > cacheManager.defineConfiguration("weather", new ConfigurationBuilder() > .persistence() > .addStore(RocksDBStoreConfigurationBuilder.class) > .location("target/data") > .expiredLocation("target/expired") > .expiration().lifespan(5, TimeUnit.SECONDS) > .build()); > cache = cacheManager.getCache("weather"); > int max = 10001; > for (int i=0; i<max; i++) { > cache.put(UUID.randomUUID().toString(), UUID.randomUUID().toString()); > } > {code} > The test took 60478ms. > 9999 = 1773 ms > 10000 = 1797 ms > Removing the queue and writing directly to RocksDB will be faster than the current code -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10963) Remove blocking queue from RocksDBStore

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10963?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-10963: --------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7605 (was: https://github.com/infinispan/infinispan/pull/7543/files) > Remove blocking queue from RocksDBStore > --------------------------------------- > > Key: ISPN-10963 > URL: https://issues.jboss.org/browse/ISPN-10963 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. > By default it will be running each minute and the client will totally block. > {code:java} > cacheManager.defineConfiguration("weather", new ConfigurationBuilder() > .persistence() > .addStore(RocksDBStoreConfigurationBuilder.class) > .location("target/data") > .expiredLocation("target/expired") > .expiration().lifespan(5, TimeUnit.SECONDS) > .build()); > cache = cacheManager.getCache("weather"); > int max = 10001; > for (int i=0; i<max; i++) { > cache.put(UUID.randomUUID().toString(), UUID.randomUUID().toString()); > } > {code} > The test took 60478ms. > 9999 = 1773 ms > 10000 = 1797 ms > Removing the queue and writing directly to RocksDB will be faster than the current code -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10964) Provide Exceptions for unsupported operations with APPLICATION_UNKNOWN

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10964?page=com.atlassian.jira.plugin... ] Ryan Emerson updated ISPN-10964: -------------------------------- Description: The default media type for cache types is APPLICATION_UNKNOWN if not explicitly configured by the user. However, APPLICATION_UNKNOWN is not supported when using the following: * Filters * Converters * Transcoders (works sometimes, best effort) Instead of failures occurring at runtime, we should throw a configuration exception where possible. In the case of the transcoder, we should either throw a more meaningful exception when transcoding fails or remove the ability to transcode APPLICATION_UNKNOWN sources. The exception(s) should instruct the user to explicitly configure the media type. was: The default media type for cache types is APPLICATION_UNKNOWN if not explicitly configured by the user. However, APPLICATION_UNKNOWN is not supported when using the following: * Filters * Converters * Transcoders (works sometimes, best effort) Instead of failures occurring at runtime, we should throw a configuration exception where possible. In the case of the transcoder, we should either throw a more meaningful exception when transcoding fails or remove the ability to transcode APPLICATION_UNKNOWN sources. > Provide Exceptions for unsupported operations with APPLICATION_UNKNOWN > ---------------------------------------------------------------------- > > Key: ISPN-10964 > URL: https://issues.jboss.org/browse/ISPN-10964 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.1.0.Beta1 > Reporter: Ryan Emerson > Priority: Major > > The default media type for cache types is APPLICATION_UNKNOWN if not explicitly configured by the user. However, APPLICATION_UNKNOWN is not supported when using the following: > * Filters > * Converters > * Transcoders (works sometimes, best effort) > Instead of failures occurring at runtime, we should throw a configuration exception where possible. In the case of the transcoder, we should either throw a more meaningful exception when transcoding fails or remove the ability to transcode APPLICATION_UNKNOWN sources. > The exception(s) should instruct the user to explicitly configure the media type. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10964) Provide Exceptions for unsupported operations with APPLICATION_UNKNOWN

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-10964: ----------------------------------- Summary: Provide Exceptions for unsupported operations with APPLICATION_UNKNOWN Key: ISPN-10964 URL: https://issues.jboss.org/browse/ISPN-10964 Project: Infinispan Issue Type: Enhancement Components: Server Affects Versions: 10.1.0.Beta1 Reporter: Ryan Emerson The default media type for cache types is APPLICATION_UNKNOWN if not explicitly configured by the user. However, APPLICATION_UNKNOWN is not supported when using the following: * Filters * Converters * Transcoders (works sometimes, best effort) Instead of failures occurring at runtime, we should throw a configuration exception where possible. In the case of the transcoder, we should either throw a more meaningful exception when transcoding fails or remove the ability to transcode APPLICATION_UNKNOWN sources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10818) ProtoStream 9.4.x client backwards compatibility

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10818?page=com.atlassian.jira.plugin... ] Ryan Emerson commented on ISPN-10818: ------------------------------------- Backwards compatibility is also an issue for old clients that utilise ProtoStream as a marshaller for key/value types. The following changes are required to ensure that old clients can interoperate with a 10.x server(s) that also interacts with a 10.x client. Changes required: ProtoStream: * A mechanism to transform TypeIds in ProtoStream byte array via WrappedMessageTypeIdMapper without unmarshalling data Server: * 10.x APPLICATION_PROTOSTREAM media type must be set as the storage type on cache * Server transforms 9.4.x (or older) client payloads for ^ cache using ProtoStream TypeId transformer and stores using the new Ids * All server responses to old clients must re-transform the payload to the old TypeIds * Storage type APPLICATION_OCTET_STREAM on the server is not supported with old ProtoStream clients as it's not possible to 100% guarantee payload is Protobuf > ProtoStream 9.4.x client backwards compatibility > ------------------------------------------------ > > Key: ISPN-10818 > URL: https://issues.jboss.org/browse/ISPN-10818 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 10.0.0.CR3 > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.1.0.Final > > > For performance reasons, ProtoStream changed the TypeId of WrappedMessage to 0, which means that pre 10.x clients using RemoteQuery are no longer compatible. Furthermore, ISPN-10663 updated the TypeId of the remote query messages to conform to the Infinispan TypeId ranges defined in ProtoStreamTypeIds. > Therefore, for pre 10.x clients, it is neccessary for all remote query requests to have the legacy TypeId mapped to the new TypeId values. https://issues.jboss.org/browse/IPROTO-119 introduced a mechanism for this mapping, however more work is required, as the mapping must occur on a per request/response basis (only if communication is with a legacy client). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10954) Add console dependency

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10954?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10954: -------------------------------- Labels: console-ng (was: ) > Add console dependency > ---------------------- > > Key: ISPN-10954 > URL: https://issues.jboss.org/browse/ISPN-10954 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 10.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > Consume the console artifact from maven and make it availabe on the server distribution -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10963) Remove blocking queue from RocksDBStore

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-10963?page=com.atlassian.jira.plugin... ] Diego Lovison updated ISPN-10963: --------------------------------- Description: Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. By default it will be running each minute and the client will totally block. {code:java} cacheManager.defineConfiguration("weather", new ConfigurationBuilder() .persistence() .addStore(RocksDBStoreConfigurationBuilder.class) .location("target/data") .expiredLocation("target/expired") .expiration().lifespan(5, TimeUnit.SECONDS) .build()); cache = cacheManager.getCache("weather"); int max = 10001; for (int i=0; i<max; i++) { cache.put(UUID.randomUUID().toString(), UUID.randomUUID().toString()); } {code} The test took 60478ms. 9999 = 1773 ms 10000 = 1797 ms Removing the queue and writing directly to RocksDB will be faster than the current code was:Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. Instead we should offer elements to the queue and upon failure utilise the persistence executors to run purge. > Remove blocking queue from RocksDBStore > --------------------------------------- > > Key: ISPN-10963 > URL: https://issues.jboss.org/browse/ISPN-10963 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. > By default it will be running each minute and the client will totally block. > {code:java} > cacheManager.defineConfiguration("weather", new ConfigurationBuilder() > .persistence() > .addStore(RocksDBStoreConfigurationBuilder.class) > .location("target/data") > .expiredLocation("target/expired") > .expiration().lifespan(5, TimeUnit.SECONDS) > .build()); > cache = cacheManager.getCache("weather"); > int max = 10001; > for (int i=0; i<max; i++) { > cache.put(UUID.randomUUID().toString(), UUID.randomUUID().toString()); > } > {code} > The test took 60478ms. > 9999 = 1773 ms > 10000 = 1797 ms > Removing the queue and writing directly to RocksDB will be faster than the current code -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7912) Prevent RocksDBStore writes blocking on full expiry queue

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-7912?page=com.atlassian.jira.plugin.... ] Diego Lovison reassigned ISPN-7912: ----------------------------------- Assignee: (was: Diego Lovison) > Prevent RocksDBStore writes blocking on full expiry queue > --------------------------------------------------------- > > Key: ISPN-7912 > URL: https://issues.jboss.org/browse/ISPN-7912 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Ryan Emerson > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. Instead we should offer elements to the queue and upon failure utilise the persistence executors to run purge. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7912) Prevent RocksDBStore writes blocking on full expiry queue

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-7912?page=com.atlassian.jira.plugin.... ] Work on ISPN-7912 started by Diego Lovison. ------------------------------------------- > Prevent RocksDBStore writes blocking on full expiry queue > --------------------------------------------------------- > > Key: ISPN-7912 > URL: https://issues.jboss.org/browse/ISPN-7912 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Diego Lovison > Priority: Major > Fix For: 10.1.0.Final > > > Currently you can only insert 10000 elements into the rocks db store until you will block a thread until the expiration reaper is ran. Instead we should offer elements to the queue and upon failure utilise the persistence executors to run purge. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2019