[JBoss JIRA] (ISPN-10428) Docs: Configuring paths for single file cache stores
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-10428?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-10428:
-------------------------------
Status: Pull Request Sent (was: Reopened)
> Docs: Configuring paths for single file cache stores
> ----------------------------------------------------
>
> Key: ISPN-10428
> URL: https://issues.redhat.com/browse/ISPN-10428
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Environment: XSD
> jboss-infinispan-core*.xsd
> infinispan-config*.xsd
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Minor
> Fix For: 9.4.19.Final
>
>
> Embedded and server mode are using a different configuration for file-store
> embedded : infinispan-config*
> {code}
> </xs:attribute>
> <xs:attribute name="relative-to" type="xs:string">
> <xs:annotation><xs:documentation>Unused XML attribute</xs:documentation></xs:annotation>
> </xs:attribute>
> <xs:attribute name="path" type="xs:string">
> <xs:annotation>
> <xs:documentation>
> The path within "relative-to" in which to store the cache state.
> If undefined, the path defaults to the cache container name.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> Here the relative-to is not used but referenced for path.
> But path is used relative to PWD if it is not an absolute one, also if defaults to 'Infinispan-SingleFileStore' if not set.
> For the server configuration it is
> {code}
> <xs:attribute name="relative-to" type="xs:string" default="jboss.server.data.dir">
> <xs:annotation>
> <xs:documentation>The base directory in which to store the cache state.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> <xs:attribute name="path" type="xs:string">
> <xs:annotation>
> <xs:documentation>
> The path within "relative-to" in which to store the cache state.
> If undefined, the path defaults to the cache container name.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> But relative-to is a reference to a path declaration like this
> {code}
> <paths>
> <path name="my.dir" path="/MyCacheStore"/>
> </paths>
> ...
> <distributed-cache name="wolf">
> <persistence>
> <file-store shared="false" fetch-state="true" relative-to="my.dir"/>
> </persistence>
> </distributed-cache>
> {code}
> If relative-to is set to a real path or env variable the server start will fail with
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.wolf.config: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.wolf.config: Failed to start service
> ...
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/MyCacheStore'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
> at org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationAdd$5.inject(CacheConfigurationAdd.java:765)
> at org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationAdd$5.inject(CacheConfigurationAdd.java:760)
> at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:58)
> at org.jboss.msc.service.ServiceControllerImpl.inject(ServiceControllerImpl.java:1517)
> at org.jboss.msc.service.ServiceControllerImpl.inject(ServiceControllerImpl.java:1503)
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:55)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1699)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-10428) Docs: Configuring paths for single file cache stores
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-10428?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-10428:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/8203, https://github.com/infinispan/infinispan/pull/8212, https://github.com/infinispan/infinispan/pull/8233 (was: https://github.com/infinispan/infinispan/pull/8203, https://github.com/infinispan/infinispan/pull/8212)
> Docs: Configuring paths for single file cache stores
> ----------------------------------------------------
>
> Key: ISPN-10428
> URL: https://issues.redhat.com/browse/ISPN-10428
> Project: Infinispan
> Issue Type: Enhancement
> Components: Documentation
> Environment: XSD
> jboss-infinispan-core*.xsd
> infinispan-config*.xsd
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Minor
> Fix For: 9.4.19.Final
>
>
> Embedded and server mode are using a different configuration for file-store
> embedded : infinispan-config*
> {code}
> </xs:attribute>
> <xs:attribute name="relative-to" type="xs:string">
> <xs:annotation><xs:documentation>Unused XML attribute</xs:documentation></xs:annotation>
> </xs:attribute>
> <xs:attribute name="path" type="xs:string">
> <xs:annotation>
> <xs:documentation>
> The path within "relative-to" in which to store the cache state.
> If undefined, the path defaults to the cache container name.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> Here the relative-to is not used but referenced for path.
> But path is used relative to PWD if it is not an absolute one, also if defaults to 'Infinispan-SingleFileStore' if not set.
> For the server configuration it is
> {code}
> <xs:attribute name="relative-to" type="xs:string" default="jboss.server.data.dir">
> <xs:annotation>
> <xs:documentation>The base directory in which to store the cache state.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> <xs:attribute name="path" type="xs:string">
> <xs:annotation>
> <xs:documentation>
> The path within "relative-to" in which to store the cache state.
> If undefined, the path defaults to the cache container name.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
> But relative-to is a reference to a path declaration like this
> {code}
> <paths>
> <path name="my.dir" path="/MyCacheStore"/>
> </paths>
> ...
> <distributed-cache name="wolf">
> <persistence>
> <file-store shared="false" fetch-state="true" relative-to="my.dir"/>
> </persistence>
> </distributed-cache>
> {code}
> If relative-to is set to a real path or env variable the server start will fail with
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.wolf.config: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.wolf.config: Failed to start service
> ...
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/MyCacheStore'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:110)
> at org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationAdd$5.inject(CacheConfigurationAdd.java:765)
> at org.jboss.as.clustering.infinispan.subsystem.CacheConfigurationAdd$5.inject(CacheConfigurationAdd.java:760)
> at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:58)
> at org.jboss.msc.service.ServiceControllerImpl.inject(ServiceControllerImpl.java:1517)
> at org.jboss.msc.service.ServiceControllerImpl.inject(ServiceControllerImpl.java:1503)
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:55)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1699)
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11699) Remove RecoveryAwareGlobalTransaction
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11699?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11699:
--------------------------------
Status: Open (was: New)
> Remove RecoveryAwareGlobalTransaction
> -------------------------------------
>
> Key: ISPN-11699
> URL: https://issues.redhat.com/browse/ISPN-11699
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev05
>
>
> Currently there exists both the {{GlobalTransaction}} and {{RecoveryAwareGlobalTransaction}} which implements {{RecoverableTransactionIdentifier}}. If we add the `Xid` and `internalId` fields to {{GlobalTransaction}}, the latter are redundant. We should remove theses classes as it simplifies the ProtoStream marshalling code required by commands such as {{PrepareCommand}} as they don't have to handle the polymorphism.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11699) Remove RecoveryAwareGlobalTransaction
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11699?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-11699:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8232
> Remove RecoveryAwareGlobalTransaction
> -------------------------------------
>
> Key: ISPN-11699
> URL: https://issues.redhat.com/browse/ISPN-11699
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev05
>
>
> Currently there exists both the {{GlobalTransaction}} and {{RecoveryAwareGlobalTransaction}} which implements {{RecoverableTransactionIdentifier}}. If we add the `Xid` and `internalId` fields to {{GlobalTransaction}}, the latter are redundant. We should remove theses classes as it simplifies the ProtoStream marshalling code required by commands such as {{PrepareCommand}} as they don't have to handle the polymorphism.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11699) Remove RecoveryAwareGlobalTransaction
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-11699?page=com.atlassian.jira.plugi... ]
Ryan Emerson reassigned ISPN-11699:
-----------------------------------
Assignee: Ryan Emerson
> Remove RecoveryAwareGlobalTransaction
> -------------------------------------
>
> Key: ISPN-11699
> URL: https://issues.redhat.com/browse/ISPN-11699
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 11.0.0.Dev04
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 11.0.0.Dev05
>
>
> Currently there exists both the {{GlobalTransaction}} and {{RecoveryAwareGlobalTransaction}} which implements {{RecoverableTransactionIdentifier}}. If we add the `Xid` and `internalId` fields to {{GlobalTransaction}}, the latter are redundant. We should remove theses classes as it simplifies the ProtoStream marshalling code required by commands such as {{PrepareCommand}} as they don't have to handle the polymorphism.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11699) Remove RecoveryAwareGlobalTransaction
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11699:
-----------------------------------
Summary: Remove RecoveryAwareGlobalTransaction
Key: ISPN-11699
URL: https://issues.redhat.com/browse/ISPN-11699
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 11.0.0.Dev04
Reporter: Ryan Emerson
Fix For: 11.0.0.Dev05
Currently there exists both the {{GlobalTransaction}} and {{RecoveryAwareGlobalTransaction}} which implements {{RecoverableTransactionIdentifier}}. If we add the `Xid` and `internalId` fields to {{GlobalTransaction}}, the latter are redundant. We should remove theses classes as it simplifies the ProtoStream marshalling code required by commands such as {{PrepareCommand}} as they don't have to handle the polymorphism.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11687) Infinispan not able to start after CR configuration change
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11687?page=com.atlassian.jira.plugi... ]
Tristan Tarrant commented on ISPN-11687:
----------------------------------------
You should attach the full exception log as well as the type of operations you are performing over HR/REST.
There is nothing in the Hot Rod protocol vs HTTP that would matter here, since they both use the same internal APIs, but interactions can be weird
> Infinispan not able to start after CR configuration change
> ----------------------------------------------------------
>
> Key: ISPN-11687
> URL: https://issues.redhat.com/browse/ISPN-11687
> Project: Infinispan
> Issue Type: Bug
> Components: OpenShift, Operator
> Affects Versions: 10.1.2.Final
> Reporter: Marian Macik
> Assignee: Vittorio Rigamonti
> Priority: Major
>
> Hi guys, as you may know, Kogito Operator uses Infinispan Operator to create a predefined Infinispan instance running on Openshift. Quite often we encounter an issue reproducible with these steps:
> 1. Install the Kogito Operator (this will also install Infinispan Operator).
> 2. Create a KogitoApp custom resource (CR) with this YAML:
> {code:yaml}
> apiVersion: app.kiegroup.org/v1alpha1
> kind: KogitoApp
> metadata:
> name: example-quarkus
> spec:
> enablePersistence: true
> build:
> envs:
> # enable persistence
> - name: MAVEN_ARGS_APPEND
> value: "-Ppersistence"
> gitSource:
> contextDir: process-quarkus-example
> uri: 'https://github.com/kiegroup/kogito-examples'
> reference: master
> {code}
> This will create a KogitoApp CR and will tell the Kogito Operator to provision Infinispan with one replica. Kogito application runs on Quarkus which makes use of RemoteCacheManager of Quarkus Infinispan Client Extension. Up to this point, everything works, application is deployed.
> 3. Try change Infinispan config by editing Infinispan CR a few times and Infinispan won't be able to start properly. By editing I mean - change one of these 3 parameters:
> {code:yaml}
> ...
> spec:
> container:
> cpu: ''
> extraJvmOpts: ''
> memory: ''
> ...
> {code}
> I generally want to change the cpu and memory as defaults are too low and I am also specifying `-Xmx2G` to extraJvmOpts so Infinispan has more heap than 200 MB which is default.
> Anyway, if you do this change a couple of times and after each change you wait until Infinispan pod is restarted, after ~5 times you will see [java.nio.channels.OverlappingFileLockException|https://gist.github.com/Ma...] in the Infinispan pod log.
> There is also another issue attached at the bottom of the Gist which was observed in Openshift events logs.
> What I have found is that if I create only KogitoInfra CR, which will create Infinispan CR and won't run any KogitoApp, so there is nothing connected to Infinispan, I can restart it how many times I want and it will work without any issues. I even tried to store something to the Infinispan via Infinispan REST API from the pod and tried changing Infinispan configuration then, and it worked like a charm after each restart.
> However, as soon as I deploy KogitoApp so it is connected to Infinispan using HotRod client and change Infinispan CR a few times (after each change waiting for Infinispan pod to restart), it will break with the linked exception present in the logs.
> To me it seems that this stops working once there is actual connection to Infinispan using HotRod client. I am not sure how this client works internally, but I would think that in addition to real user data there is some sort of exchange of "control data" let's say in this protocol between client and Infinispan which might break if Infinispan is suddenly restarted? Not sure, but with pushing there data using REST API (so without HotRod client) where the connection is maintained only for the time of the request, the exception didn't occur.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11687) Infinispan not able to start after CR configuration change
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11687?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11687:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8231
> Infinispan not able to start after CR configuration change
> ----------------------------------------------------------
>
> Key: ISPN-11687
> URL: https://issues.redhat.com/browse/ISPN-11687
> Project: Infinispan
> Issue Type: Bug
> Components: OpenShift, Operator
> Affects Versions: 10.1.2.Final
> Reporter: Marian Macik
> Assignee: Vittorio Rigamonti
> Priority: Major
>
> Hi guys, as you may know, Kogito Operator uses Infinispan Operator to create a predefined Infinispan instance running on Openshift. Quite often we encounter an issue reproducible with these steps:
> 1. Install the Kogito Operator (this will also install Infinispan Operator).
> 2. Create a KogitoApp custom resource (CR) with this YAML:
> {code:yaml}
> apiVersion: app.kiegroup.org/v1alpha1
> kind: KogitoApp
> metadata:
> name: example-quarkus
> spec:
> enablePersistence: true
> build:
> envs:
> # enable persistence
> - name: MAVEN_ARGS_APPEND
> value: "-Ppersistence"
> gitSource:
> contextDir: process-quarkus-example
> uri: 'https://github.com/kiegroup/kogito-examples'
> reference: master
> {code}
> This will create a KogitoApp CR and will tell the Kogito Operator to provision Infinispan with one replica. Kogito application runs on Quarkus which makes use of RemoteCacheManager of Quarkus Infinispan Client Extension. Up to this point, everything works, application is deployed.
> 3. Try change Infinispan config by editing Infinispan CR a few times and Infinispan won't be able to start properly. By editing I mean - change one of these 3 parameters:
> {code:yaml}
> ...
> spec:
> container:
> cpu: ''
> extraJvmOpts: ''
> memory: ''
> ...
> {code}
> I generally want to change the cpu and memory as defaults are too low and I am also specifying `-Xmx2G` to extraJvmOpts so Infinispan has more heap than 200 MB which is default.
> Anyway, if you do this change a couple of times and after each change you wait until Infinispan pod is restarted, after ~5 times you will see [java.nio.channels.OverlappingFileLockException|https://gist.github.com/Ma...] in the Infinispan pod log.
> There is also another issue attached at the bottom of the Gist which was observed in Openshift events logs.
> What I have found is that if I create only KogitoInfra CR, which will create Infinispan CR and won't run any KogitoApp, so there is nothing connected to Infinispan, I can restart it how many times I want and it will work without any issues. I even tried to store something to the Infinispan via Infinispan REST API from the pod and tried changing Infinispan configuration then, and it worked like a charm after each restart.
> However, as soon as I deploy KogitoApp so it is connected to Infinispan using HotRod client and change Infinispan CR a few times (after each change waiting for Infinispan pod to restart), it will break with the linked exception present in the logs.
> To me it seems that this stops working once there is actual connection to Infinispan using HotRod client. I am not sure how this client works internally, but I would think that in addition to real user data there is some sort of exchange of "control data" let's say in this protocol between client and Infinispan which might break if Infinispan is suddenly restarted? Not sure, but with pushing there data using REST API (so without HotRod client) where the connection is maintained only for the time of the request, the exception didn't occur.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months