[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months
[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)
5 years, 10 months