[JBoss JIRA] (ISPN-10428) Document declarative configuration of file-stores
by Donald Naro (Jira)
[ https://issues.jboss.org/browse/ISPN-10428?page=com.atlassian.jira.plugin... ]
Donald Naro updated ISPN-10428:
-------------------------------
Component/s: Documentation-Servers
(was: Core)
(was: Server)
> Document declarative configuration of file-stores
> -------------------------------------------------
>
> Key: ISPN-10428
> URL: https://issues.jboss.org/browse/ISPN-10428
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Servers
> Environment: XSD
> jboss-infinispan-core*.xsd
> infinispan-config*.xsd
> Reporter: Wolf-Dieter Fink
> Assignee: Donald Naro
> Priority: Minor
>
> 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.5#713005)
6 years, 7 months
[JBoss JIRA] (ISPN-4610) Implement total order for non-transactional caches
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-4610?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4610:
------------------------------
Priority: Optional (was: Major)
> Implement total order for non-transactional caches
> --------------------------------------------------
>
> Key: ISPN-4610
> URL: https://issues.jboss.org/browse/ISPN-4610
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Optional
>
> Current locking algorithm in non-transactional caches needs a remote thread on the primary owner to block while replicating the update to the backup owner. The thread is also holding the lock for the key, so it's blocking other threads that want to write to the same key. When there is a lot of contention, this can exhaust the remote executor thread pool and cause lock timeouts.
> TO was designed with high contention in mind, and it doesn't block threads to acquire locks. So it should handle this much better.
> An alternative solution would be the locking rework in ISPN-2849.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 7 months
[JBoss JIRA] (ISPN-3189) Extend Grouping API to mapping of DeltaCompositeKeys to the same node as the delta aware value key
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-3189?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo closed ISPN-3189.
-----------------------------
Resolution: Out of Date
{{DeltaCompositeKey}} was removed.
> Extend Grouping API to mapping of DeltaCompositeKeys to the same node as the delta aware value key
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-3189
> URL: https://issues.jboss.org/browse/ISPN-3189
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 5.3.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Minor
>
> Try to understand and analyze the performance impact to extended the Grouping API to support the DeltaCompositeKey and return the owners based on the delta aware value key.
> In the current implementation, the interceptors are responsible to check if the key is a DeltaCompositeKey instance and check for the ownership based on the delta aware value key.
> Pros and cons of using an extension of Grouping API
> Pros:
> * this check for DeltaCompositeKey instance is done in a single point instead of being spread in the code.
> * less error prone
> Cons:
> * possible performance impact since all the getSegment(key) invocations should perform the check.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 7 months