August 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10032) unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Ryan Emerson resolved ISPN-10032. --------------------------------- Fix Version/s: 10.0.0.Beta5 Resolution: Done > unclear lifespan expiration lifespan value (seconds or UnixTime) for expiration for remote access with HotRod > ------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10032 > URL: https://issues.jboss.org/browse/ISPN-10032 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.8.Final, 10.0.0.Beta2 > Reporter: Wolf-Dieter Fink > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 10.0.0.Beta5 > > > The documentation of the org.infinispan.client.hotrod.RemoteCache API is confusing. The Class header explain that lifespan expiration will use Seconds or UnitTime depend on the given value but the methods with lifespan will not reflect that with a hint. > API document ([Upstream 9.4| https://docs.jboss.org/infinispan/9.4/apidocs/org/infinispan/client/hotro...] > contains the explanation as followed: > {quote} > *Eviction and expiration:* Unlike local Cache cache, which allows specifying time values with any granularity (as defined by TimeUnit), HotRod only supports seconds as time units. If a different time unit is used instead, HotRod will transparently convert it to seconds, using TimeUnit.toSeconds(long) method. This might result in loss of precision for values specified as nanos or milliseconds. > Another fundamental difference is in the case of lifespan (naturally does NOT apply for max idle): *If number of seconds is bigger than 30 days, this number of seconds is treated as UNIX time and so, represents the number of seconds since 1/1/1970.* > {quote} > But the behavior is different for different ISPN releases. When the specified lifespan value is bigger than 30 days: > - ISPN <=6.2: the value >30days is treated as UNIX time expiry > - ISPN >6.2 <=8.3: the specified value (the maximum is Integer.MAX_VALUE) is treated as lifespan for Hot Rod protocol 2.2 or later. > And as UNIX time expiry for Hot Rod protocol 2.1 or before. > - >8.3: the value >30days is treated as UNIX time expiry regardless of Hot Rod protocol version > According to the API for embedded mode and the method parameters the lifespan should be always treated as seconds, never as UNIX time -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10266) Spring Cache doesn't remove the cache or update the cache configuration

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10266?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10266: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 9.4.16.Final Resolution: Done > Spring Cache doesn't remove the cache or update the cache configuration > ----------------------------------------------------------------------- > > Key: ISPN-10266 > URL: https://issues.jboss.org/browse/ISPN-10266 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.14.Final > Reporter: Diego Lovison > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta5, 9.4.16.Final > > > After ISPN-10171, the Spring Cache doesn't remove the cache or update the cache configuration. > I am expecting the cache to be null once it was removed from remote cache manager. > {code:java} > @Test > public final void getCacheShouldReturnNullItWasChangedByRemoteCacheManager() { > // Given > objectUnderTest = new SpringRemoteCacheManager(remoteCacheManager); > // When > objectUnderTest.getCache(TEST_CACHE_NAME); > remoteCacheManager.administration().removeCache(TEST_CACHE_NAME); > // Then > assertNull(objectUnderTest.getCache(TEST_CACHE_NAME)); > } > {code} > I am expecting a different instance of the cache once the configuration was changed. > {code:java} > @Test > public final void getCacheShouldReturnDiffInstanceItWasChangedByRemoteCacheManager() { > // Given > objectUnderTest = new SpringRemoteCacheManager(remoteCacheManager); > // When > final SpringCache firstObtainedSpringCache = objectUnderTest.getCache(TEST_CACHE_NAME); > remoteCacheManager.administration().removeCache(TEST_CACHE_NAME); > remoteCacheManager.administration().createCache(TEST_CACHE_NAME, cacheManager.getDefaultCacheConfiguration()); > // Then > final SpringCache secondObtainedSpringCache = objectUnderTest.getCache(TEST_CACHE_NAME); > assertNotSame( > "getCache() shouldn't have the same SpringCache instance for the same name because the config was changed", > firstObtainedSpringCache, secondObtainedSpringCache); > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10452) Remove AsElementAttributeSerializer

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10452?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10452: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 Resolution: Done > Remove AsElementAttributeSerializer > ----------------------------------- > > Key: ISPN-10452 > URL: https://issues.jboss.org/browse/ISPN-10452 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.0.0.Beta5 > > > The JSON rendering currently is based on inspecting Attributes in Configuration(Builder) classes, and it's also possible to plug-in an AttributeSerializer that will emit the Attribute as a JSON Object rather than a field (property name/value pair) inside a JSON object. > Sometimes it's not always clear what will be the rendered JSON when attributes can be objects and vice-versa, so JSON objects should be generated from Configuration objects and JSON fields should be generated from the Configuration's Attributes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10451) JDBC store segment-column not serialized and not in schema

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10451?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10451: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 Resolution: Done > JDBC store segment-column not serialized and not in schema > ---------------------------------------------------------- > > Key: ISPN-10451 > URL: https://issues.jboss.org/browse/ISPN-10451 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 10.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10425) Update Netty and RxJava2 to align with Quarkus dependencies

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10425?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10425: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 (was: 10.0.0.Final) Resolution: Done > Update Netty and RxJava2 to align with Quarkus dependencies > ----------------------------------------------------------- > > Key: ISPN-10425 > URL: https://issues.jboss.org/browse/ISPN-10425 > Project: Infinispan > Issue Type: Task > Components: Dependency > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Beta5 > > > Quarkus uses Vert.x and smallrye reactive streams. Both of these use specific versions of netty and RxJava2 respectively. We should make sure we use the same versions to ensure compatibility as much as possible. > Vert.x (Netty 4.1.34) > https://github.com/quarkusio/quarkus/blob/master/build-parent/pom.xml#L34 > https://github.com/vert-x3/vertx-dependencies/blob/3.7/pom.xml#L51 > https://github.com/vert-x3/vertx-dependencies/blob/116e1fe31a5130c2e5b33b... > SmallRye Reactive Streams (2.2.9 RxJava2) > https://github.com/quarkusio/quarkus/blob/master/bom/runtime/pom.xml#L41 > https://github.com/smallrye/smallrye-reactive-streams-operators/blob/779a... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9942) Cache Manager resource

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9942?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9942: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta5 Resolution: Done > Cache Manager resource > ---------------------- > > Key: ISPN-9942 > URL: https://issues.jboss.org/browse/ISPN-9942 > Project: Infinispan > Issue Type: Sub-task > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > Fix For: 10.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10457) Convert bulk blocking invocations to non blocking

by Will Burns (Jira)

Will Burns created ISPN-10457: --------------------------------- Summary: Convert bulk blocking invocations to non blocking Key: ISPN-10457 URL: https://issues.jboss.org/browse/ISPN-10457 Project: Infinispan Issue Type: Enhancement Reporter: Will Burns Fix For: 10.0.0.Final We now have the non blocking DistributedPublisher for single response values. We should use this or some other public API instead of the blocking bulk operations. For example size method is blocking and we should use the appropriate one instead. Methods using iteration over entrySet or keySet cannot yet be converted unfortunately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10161) ThreadLeakChecker is blocking PolarionJUnitXMLReporter to generate the reports

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-10161?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-10161: -------------------------------- Sprint: DataGrid Sprint #30, DataGrid Sprint #31 (was: DataGrid Sprint #30) > ThreadLeakChecker is blocking PolarionJUnitXMLReporter to generate the reports > ------------------------------------------------------------------------------ > > Key: ISPN-10161 > URL: https://issues.jboss.org/browse/ISPN-10161 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.12.Final, 10.0.0.Final > Reporter: Diego Lovison > Assignee: Dan Berindei > Priority: Critical > > When we have Leaked threads we are throwing a new RuntimeException that is preventing the next listener to be running. > From `master` execute `rm -rf hibernate/cache-v51/target/surefire-reports/ && rm -rf hibernate/cache-v53/target/surefire-reports/ && mvn verify -pl hibernate/cache-v51,hibernate/cache-v53 -Dtest=MultiTenancyTest -fae` > After that, check the hibernate/cache-v53/target/surefire-reports/ folder, you will see no reports there. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9541) Module initialization is not thread-safe

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9541: ------------------------------- Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1) > Module initialization is not thread-safe > ---------------------------------------- > > Key: ISPN-9541 > URL: https://issues.jboss.org/browse/ISPN-9541 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 9.4.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work. > Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks. > The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log. > I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9541) Module initialization is not thread-safe

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9541: ------------------------------- Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31) > Module initialization is not thread-safe > ---------------------------------------- > > Key: ISPN-9541 > URL: https://issues.jboss.org/browse/ISPN-9541 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 9.4.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work. > Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks. > The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log. > I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2019