March 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10514) Server Docs: Describe various methods to create caches

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10514?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-10514. ------------------------------ Resolution: Duplicate Issue > Server Docs: Describe various methods to create caches > ------------------------------------------------------ > > Key: ISPN-10514 > URL: https://issues.redhat.com/browse/ISPN-10514 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Also describes the default cache templates and how to retrieve them via rest and cli. > As a user, I want to create caches at startup. > As a user, I want to create caches on the fly/dynamically. > As a user, I want to create permanent caches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9650) Docs: Migration to clustered executor from distributed executor

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-9650?page=com.atlassian.jira.plugin... ] Donald Naro closed ISPN-9650. ----------------------------- Resolution: Won't Do > Docs: Migration to clustered executor from distributed executor > --------------------------------------------------------------- > > Key: ISPN-9650 > URL: https://issues.redhat.com/browse/ISPN-9650 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 9.4.0.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > User Guide and Javadoc have details on clustered executor. Need to explain how to migrate from distributed executor to clustered executor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10799) Docs: Data Stored Directly Via A Hot Rod Client has CacheValue that doesn't exists

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10799?page=com.atlassian.jira.plugi... ] Donald Naro commented on ISPN-10799: ------------------------------------ [~dlovison] hi, can you check this out please before I close it? I think we've fixed this as part of the doc work on 10.x but I'd like to be sure it isn't an issue for 10.1 docs. thank you. > Docs: Data Stored Directly Via A Hot Rod Client has CacheValue that doesn't exists > ----------------------------------------------------------------------------------- > > Key: ISPN-10799 > URL: https://issues.redhat.com/browse/ISPN-10799 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Affects Versions: 10.0.0.CR3 > Reporter: Diego Lovison > Assignee: Donald Naro > Priority: Major > > In the document section "Data Stored Directly Via A Hot Rod Client" ( https://infinispan.org/docs/latest/user_guide/user_guide.html#data_stored... ) we have a code example that is using GenericJBossMarshaller with CacheValue > CacheValue was removed from the source code > There are 26 entries for CacheValue that we need to review as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10428) 7.3 Docs: Document declarative configuration of file-stores

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10428?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-10428. ------------------------------ Resolution: Won't Do > 7.3 Docs: Document declarative configuration of file-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 > > 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)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9355) Some API links in user guide are broken

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-9355?page=com.atlassian.jira.plugin... ] Donald Naro closed ISPN-9355. ----------------------------- Resolution: Won't Do The User Guide exists for older versions only. As of 10.x we're using a different strategy for maintaining links to packages and API docs to reduce the likelihood of broken links. > Some API links in user guide are broken > --------------------------------------- > > Key: ISPN-9355 > URL: https://issues.redhat.com/browse/ISPN-9355 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 9.3.0.Final > Reporter: Steven Hawkins > Assignee: Donald Naro > Priority: Major > > On pages such as http://infinispan.org/docs/stable/user_guide/user_guide.html links to some Infinispan javadocs are pointing to the older package locations. For example: https://docs.jboss.org/infinispan/9.3/apidocs/org/infinispan/commons/api/... > There appears to be nearly 50 such broken links. > Additionally https://jira.jboss.org/browse/ISPN/component/12312732 no longer exists. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11512) The mass indexer should iterate over the cache only once

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11512?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11512: ------------------------------------- Status: Open (was: New) > The mass indexer should iterate over the cache only once > -------------------------------------------------------- > > Key: ISPN-11512 > URL: https://issues.redhat.com/browse/ISPN-11512 > Project: Infinispan > Issue Type: Enhancement > Components: Indexing > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final > > > {{DistributedExecutorMassIndexer}} starts an {{IndexWorker}} for each indexed type and submits them to all the nodes in parallel. Each {{IndexWorker}} runs a blocking iteration over the cache, and when the cache has a store, that iteration is very expensive. > Each iteration will load and deserialize all the entries in the store. Most stores don't implement {{AbstractSegmentedStoreConfiguration}}, so Infinispan wraps them in a {{ComposedSegmentedLoadWriteStore}}, which iterates over each segment in parallel on the persistence/blocking executor. Since the default number of segments is 256 and the persistence/blocking executor has 4*cpu_count/150 max threads, it doesn't take a lot of parallel iterations to fill the blocking executor's threads and prevent the cache from doing other, more urgent, work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11513) ComposedSegmentedLoadWriteStore should not iterate over segments in parallel

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11513?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11513: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8085 > ComposedSegmentedLoadWriteStore should not iterate over segments in parallel > ---------------------------------------------------------------------------- > > Key: ISPN-11513 > URL: https://issues.redhat.com/browse/ISPN-11513 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04, 11.0.0.Final > > > {{ComposedSegmentedLoadWriteStore}} always parallelizes iterations, even when the consumer is a single thread doing a blocking iteration like {{cache.keySet().forEach(...)}}. This will use lots of blocking threads, and will crowd out single-key cache operations, which are more sensitive to latency (because there are usually multiple single-key operations for each user request). > It would be interesting to extend the persistence SPI so that the store knows when the user requested parallel iteration, but in the meantime it's safer to iterate over the segments in sequence. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11513) ComposedSegmentedLoadWriteStore should not iterate over segments in parallel

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11513?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11513: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 11.0.0.Dev04 Resolution: Done > ComposedSegmentedLoadWriteStore should not iterate over segments in parallel > ---------------------------------------------------------------------------- > > Key: ISPN-11513 > URL: https://issues.redhat.com/browse/ISPN-11513 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04, 11.0.0.Final > > > {{ComposedSegmentedLoadWriteStore}} always parallelizes iterations, even when the consumer is a single thread doing a blocking iteration like {{cache.keySet().forEach(...)}}. This will use lots of blocking threads, and will crowd out single-key cache operations, which are more sensitive to latency (because there are usually multiple single-key operations for each user request). > It would be interesting to extend the persistence SPI so that the store knows when the user requested parallel iteration, but in the meantime it's safer to iterate over the segments in sequence. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11513) ComposedSegmentedLoadWriteStore should not iterate over segments in parallel

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11513?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11513: -------------------------------- Status: Open (was: New) > ComposedSegmentedLoadWriteStore should not iterate over segments in parallel > ---------------------------------------------------------------------------- > > Key: ISPN-11513 > URL: https://issues.redhat.com/browse/ISPN-11513 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.5.Final, 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04, 11.0.0.Final > > > {{ComposedSegmentedLoadWriteStore}} always parallelizes iterations, even when the consumer is a single thread doing a blocking iteration like {{cache.keySet().forEach(...)}}. This will use lots of blocking threads, and will crowd out single-key cache operations, which are more sensitive to latency (because there are usually multiple single-key operations for each user request). > It would be interesting to extend the persistence SPI so that the store knows when the user requested parallel iteration, but in the meantime it's safer to iterate over the segments in sequence. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-11514) CacheMgmtInterceptor getNumberOfEntries should include expired entries

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11514?page=com.atlassian.jira.plugi... ] Dan Berindei reassigned ISPN-11514: ----------------------------------- Assignee: Dan Berindei > CacheMgmtInterceptor getNumberOfEntries should include expired entries > ---------------------------------------------------------------------- > > Key: ISPN-11514 > URL: https://issues.redhat.com/browse/ISPN-11514 > Project: Infinispan > Issue Type: Feature Request > Components: API, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > {{CacheMgmtInterceptor.getNumberOfEntries}} and {{CacheMgmtInterceptor.getNumberOfEntriesInMemory}} both require an iteration over the data container and/or stores in order to exclude expired entries. > Since these are statistics, they don't have to be exact, so we can include expired entries until a read or the expiration reaper removes them from the cache. In fact, I would argue that it's more correct for {{CacheMgmtInterceptor.getNumberOfEntriesInMemory}} to include expired entries, because expired entries still use memory until they are removed. > The most likely reason that the strategy for counting entries was changed with ISPN-7686 is that the {{AdvancedCache}} doesn't have a {{sizeIncludingExpired}} method. Since it's not possible to obtain the exact size of the cache with passivation enabled without iterating over the store to eliminate duplicates, I suggest instead to estimate {{CacheMgmtInterceptor.getNumberOfEntries}} as the number of entries in the data container + the number of entries in the store. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2020