May 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11930) Convert RocksDBStore to new Store SPI

by Will Burns (Jira)

Will Burns created ISPN-11930: --------------------------------- Summary: Convert RocksDBStore to new Store SPI Key: ISPN-11930 URL: https://issues.redhat.com/browse/ISPN-11930 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Will Burns Assignee: Will Burns Fix For: 11.0.0.Final Now that we have the new Store SPI we can convert RocksDBStore to utilize it. This will allow us to do a batch atomically for a transaction. Prior we could only do the write and remove portion of it atomically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11929) Boolean query in cache detail

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11929?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11929: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8403 > Boolean query in cache detail > ----------------------------- > > Key: ISPN-11929 > URL: https://issues.redhat.com/browse/ISPN-11929 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Add a property to decide if the cache can be query or not -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11929) Boolean query in cache detail

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11929?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11929: -------------------------------- Status: Open (was: New) > Boolean query in cache detail > ----------------------------- > > Key: ISPN-11929 > URL: https://issues.redhat.com/browse/ISPN-11929 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Add a property to decide if the cache can be query or not -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11929) Boolean query in cache detail

by Katia Aresti (Jira)

Katia Aresti created ISPN-11929: ----------------------------------- Summary: Boolean query in cache detail Key: ISPN-11929 URL: https://issues.redhat.com/browse/ISPN-11929 Project: Infinispan Issue Type: Enhancement Components: REST Affects Versions: 11.0.0.CR1 Reporter: Katia Aresti Assignee: Katia Aresti Add a property to decide if the cache can be query or not -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11926) Remote JCacheManager creates two RemoteCacheManager instances

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11926?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11926: -------------------------------- Status: Open (was: New) > Remote JCacheManager creates two RemoteCacheManager instances > ------------------------------------------------------------- > > Key: ISPN-11926 > URL: https://issues.redhat.com/browse/ISPN-11926 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, JCache > Affects Versions: 11.0.0.CR1, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > {{org.infinispan.jcache.remote.JCacheManager}} creates two {{RemoteCacheManager}} instances, one with {{forceReturnValues(false)}} and one with {{forceReturnValues(true)}}. This is wasteful, because each {{RemoteCacheManager}} will create its own server connections and threads. > It also breaks {{JCache}} listeners when the user explicitly sets the marshaller to {{org.infinispan.commons.marshall.ProtoStreamMarshaller}}, because {{JCacheManager}} registers the {{KeyValueWithPrevious}} marshaller (from {{GlobalContextInitializer}}) in only one of the managers. > The test suites work by accident: > * The {{jcache/remote}} test suite doesn't configure a marshaller, instead {{ConfigurationBuilder.build()}} creates a {{ProtostreamMarshaller}} instance (because {{jboss-marshalling}} is not on the classpath) and the next {{Configuration.build()}} call uses **the same {{ProtostreamMarshaller}} instance**, so the {{RemoteCacheManager}}s share the serialization context. > * The {{jcache/tck-runner-remote}} test suite has {{jboss-marshalling}} on the classpath from the {{server/runtime}} dependency, so it uses {{GenericJBossMarshaller}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11928) Rest /v2/server/env should utilise System.getProperties()

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-11928: ----------------------------------- Summary: Rest /v2/server/env should utilise System.getProperties() Key: ISPN-11928 URL: https://issues.redhat.com/browse/ISPN-11928 Project: Infinispan Issue Type: Enhancement Components: REST Affects Versions: 11.0.0.CR1 Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 11.0.0.Final Currently {{ServerResource#env}} utilises {{ManagementFactory.getRuntimeMXBean().getSystemProperties()}} in order to return system properties. The {{java.lang.management}} package is not supported with GraalVM native compilation, therefore we should simply use {{System.getProperties}} instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11927) Remove Util#threadDump java.lang.management dependencies

by Ryan Emerson (Jira)

Ryan Emerson created ISPN-11927: ----------------------------------- Summary: Remove Util#threadDump java.lang.management dependencies Key: ISPN-11927 URL: https://issues.redhat.com/browse/ISPN-11927 Project: Infinispan Issue Type: Enhancement Components: REST Affects Versions: 11.0.0.CR1 Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 11.0.0.Final Currently {{Util#threadDump}} utilises {{java.lang.management.ManagementFactory}} and {{java.lang.management.ThreadMXBean}} to generate the thread dump string. Neither of these classes work with GraalVM native compilation, therefore we should generate this String using {{Thread.getAllStackTraces}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11926) Remote JCacheManager creates two RemoteCacheManager instances

by Dan Berindei (Jira)

Dan Berindei created ISPN-11926: ----------------------------------- Summary: Remote JCacheManager creates two RemoteCacheManager instances Key: ISPN-11926 URL: https://issues.redhat.com/browse/ISPN-11926 Project: Infinispan Issue Type: Bug Components: Hot Rod, JCache Affects Versions: 10.1.8.Final, 11.0.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 11.0.0.Final {{org.infinispan.jcache.remote.JCacheManager}} creates two {{RemoteCacheManager}} instances, one with {{forceReturnValues(false)}} and one with {{forceReturnValues(true)}}. This is wasteful, because each {{RemoteCacheManager}} will create its own server connections and threads. It also breaks {{JCache}} listeners when the user explicitly sets the marshaller to {{org.infinispan.commons.marshall.ProtoStreamMarshaller}}, because {{JCacheManager}} registers the {{KeyValueWithPrevious}} marshaller (from {{GlobalContextInitializer}}) in only one of the managers. The test suites work by accident: * The {{jcache/remote}} test suite doesn't configure a marshaller, instead {{ConfigurationBuilder.build()}} creates a {{ProtostreamMarshaller}} instance (because {{jboss-marshalling}} is not on the classpath) and the next {{Configuration.build()}} call uses **the same {{ProtostreamMarshaller}} instance**, so the {{RemoteCacheManager}}s share the serialization context. * The {{jcache/tck-runner-remote}} test suite has {{jboss-marshalling}} on the classpath from the {{server/runtime}} dependency, so it uses {{GenericJBossMarshaller}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11910) Server should see application/octet-stream as protostream

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11910?page=com.atlassian.jira.plugi... ] Dan Berindei commented on ISPN-11910: ------------------------------------- Looks like clients only use {{application/unknown}} for the initial PING operation. Instead {{StorageConfigurationManager}} has some logic (copied from {{DataConversion}}) that uses storage media type {{application/unknown}} in the server, if the storage type is {{OBJECT}}/{{HEAP}}. This doesn't make any difference for read/write operations, where the conversion between the request media type (e.g. {{application/x-protostream}} or {{application/x-jboss-marshalling}}) and the storage media type {{application/unknown}} is a no-op. But event converters like {{KeyValueWithPreviousEventConverter}} use request media type (aka {{format}}) {{application/x-java-object}}, and the cache needs to use the right marshaller to transcode between {{application/unknown}} and {{application/x-java-object}}. Since the server always forces {{BinaryTranscoder}} to use {{GenericJBossMarshaller}}, this means a server cache with {{OBJECT}}/{{HEAP}} storage will use {{GenericJBossMarshaller}} for transcoding {{application/unknown}} <-> {{application/x-java-object}}, even when the user marshaller is {{ProtostreamMarshaller}}. > Server should see application/octet-stream as protostream > --------------------------------------------------------- > > Key: ISPN-11910 > URL: https://issues.redhat.com/browse/ISPN-11910 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > The server, and Infinispan in general, should use the user marshaller to read {{application/octet-stream}} and {{application/unknown}} data. > ISPN-10433 added a hack in the server (for backwards compatibility, I assume): if {{jboss-marshalling}} is on the classpath, {{org.infinispan.server.core.LifecycleCallbacks.cacheManagerStarting()}} changes the marshaller for {{application/unknown}} (but not for {{application/octet-stream}}) to {{GenericJBossMarshaller}}. > This means that {{server/core}}, {{server/hotrod}}, and {{client/hotrod-client}} tests see {{application/unknown}} as protostream, but the server distribution in {{server/runtime}} always includes {{jboss-marshalling}}, so the server distribution sees {{application/unknown}} as {{GenericJBossMarshaller}} data. > It would be much better if the server always used the user marshaller for {{application/unknown}}, and when a user needs backwards compatibility between a new server and an old client, they should configure {{GenericJBossMarshaller}} in the server. > In addition, new clients should not use {{application/unknown}} unless the marshaller does not implement {{getMediaType()}}: they know the marshaller's media type, and they should send it to the server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11925) Docs: Remove examples with deprecated thread pool config

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-11925?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-11925: ------------------------------- Description: org.infinispan.configuration.cache.AsyncStoreConfiguration#threadPoolSize() is deprecated along with several other thread pool config bits. need to update examples in docs. was: https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/topic/d... > Docs: Remove examples with deprecated thread pool config > -------------------------------------------------------- > > Key: ISPN-11925 > URL: https://issues.redhat.com/browse/ISPN-11925 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > > org.infinispan.configuration.cache.AsyncStoreConfiguration#threadPoolSize() is deprecated along with several other thread pool config bits. need to update examples in docs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2020