[JBoss JIRA] (ISPN-8863) Initial Infinispan subsystem cannot be created via CLI
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8863?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8863:
-------------------------------
Attachment: no-ispn.xml
> Initial Infinispan subsystem cannot be created via CLI
> ------------------------------------------------------
>
> Key: ISPN-8863
> URL: https://issues.jboss.org/browse/ISPN-8863
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.2.0.CR2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Attachments: no-ispn.xml
>
>
> If the infinispan server is created with a .xml file that does not contain a {code}<subsystem xmlns="urn:infinispan:server:core:9.2"><cache-container>...</cache-container></subsystem{code} entry, then it's not possible to initialise the subsystem via CLI DMR operations.
> Executing {code}/subsystem=datagrid-infinispan:add(){code} results in the following server error:
> {code}
> 16:46:18,701 INFO [org.jboss.as.clustering.infinispan] (management-handler-thread - 2) Activating Infinispan subsystem.
> 16:46:18,705 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "datagrid-infinispan")]): java.lang.IllegalStateException
> at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:74)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8863) Initial Infinispan subsystem cannot be created via CLI
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-8863:
----------------------------------
Summary: Initial Infinispan subsystem cannot be created via CLI
Key: ISPN-8863
URL: https://issues.jboss.org/browse/ISPN-8863
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.2.0.CR2
Reporter: Ryan Emerson
Assignee: Ryan Emerson
If the infinispan server is created with a .xml file that does not contain a {code}<subsystem xmlns="urn:infinispan:server:core:9.2"><cache-container>...</cache-container></subsystem{code} entry, then it's not possible to initialise the subsystem via CLI DMR operations.
Executing {code}/subsystem=datagrid-infinispan:add(){code} results in the following server error:
{code}
16:46:18,701 INFO [org.jboss.as.clustering.infinispan] (management-handler-thread - 2) Activating Infinispan subsystem.
16:46:18,705 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "datagrid-infinispan")]): java.lang.IllegalStateException
at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:74)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8861:
-------------------------------------
Unfortunately we would still have to go to the remote database to make sure there are not extra entries. In this case we still have an essentially unbounded query which will return everything - so we might as well utilize what it returned. And actually by going remote we would then have N requests to the database to go over everything (until we have segment based stores) - instead of just 1. This would put even more strain on the underlying remote store implementation.
> DIST Iteration shouldn't go remote when a shared cache store is present
> -----------------------------------------------------------------------
>
> Key: ISPN-8861
> URL: https://issues.jboss.org/browse/ISPN-8861
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.3.0.Final
>
>
> When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-8861:
------------------------------------
This behaviour should be able to be toggled on/off. I'm thinking in certain situations, i.e. a remote database outside the infinispan cluster, it might be quicker to go remote within the local cluster.
> DIST Iteration shouldn't go remote when a shared cache store is present
> -----------------------------------------------------------------------
>
> Key: ISPN-8861
> URL: https://issues.jboss.org/browse/ISPN-8861
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.3.0.Final
>
>
> When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8862) Iteration and stream operations with passivation disabled shouldn't use in memory
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8862?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8862:
--------------------------------
Description:
When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is when passivation is disabled.
[1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
was:
When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is.
[1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> Iteration and stream operations with passivation disabled shouldn't use in memory
> ---------------------------------------------------------------------------------
>
> Key: ISPN-8862
> URL: https://issues.jboss.org/browse/ISPN-8862
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.3.0.Final
>
>
> When passivation is disabled all entries are assumed to be in the cache loader/store. We currently try to merge these together in a sloppy way [1]. This first reads in memory and then from the store and keeps all keys from in memory to exclude them from the store. Unfortunately the store still has to pull the entries even for the already read keys, but just ignores them. This leads to a lot of inefficiency and memory bloat. Instead we should just return the store entries as is when passivation is disabled.
> [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present
by William Burns (JIRA)
William Burns created ISPN-8861:
-----------------------------------
Summary: DIST Iteration shouldn't go remote when a shared cache store is present
Key: ISPN-8861
URL: https://issues.jboss.org/browse/ISPN-8861
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Reporter: William Burns
Assignee: William Burns
Fix For: 9.3.0.Final
When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-8860) Lazy start counter's caches
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8860:
---------------------------------
Summary: Lazy start counter's caches
Key: ISPN-8860
URL: https://issues.jboss.org/browse/ISPN-8860
Project: Infinispan
Issue Type: Enhancement
Components: Clustered Counter
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Goal: if counter's are used, there is no need to start counter's caches!
Main change:
* remove {{__counter_configuration}} and use the {{state-cache}} to store counter's configuration
Summary:
* When the first counter is defined and stored in the {{state-cache}}, the {{__counter}} cache is started.
* When a node joins, it starts the {{__counter}} cache if it finds a counter's configured stored
* We need to persist the counter's configuration (for persisted counters only!) manually since the {{state-cache}} isn't persisted
Issues
* the {{state-cache}} is available during partitions! same counter can be defined with different configuration :(
users have to deal with it while I can't find a way to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ISPN-6026) Segment-aware shared cache stores
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6026?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-6026:
-----------------------------------
Assignee: William Burns (was: Ryan Emerson)
> Segment-aware shared cache stores
> ---------------------------------
>
> Key: ISPN-6026
> URL: https://issues.jboss.org/browse/ISPN-6026
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Tristan Tarrant
> Assignee: William Burns
>
> Shared cache stores (e.g. JDBC) should be segment-aware so that they only load the keys they own.
> Possible implementation: add a segment id column, so that the store can SELECT * FROM table WHERE segment_id = segment
> Need to think about how to reconstruct segment ids.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month