July 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10375) Simple tutorials doc ascii doc style

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10375?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10375: ------------------------------- Sprint: DataGrid Sprint #32 > Simple tutorials doc ascii doc style > ------------------------------------ > > Key: ISPN-10375 > URL: https://issues.jboss.org/browse/ISPN-10375 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Katia Aresti > Assignee: Donald Naro > Priority: Minor > > simple tutorials part of the infinispan web site would benefit of being ascii doc style documentation -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10229) NullPointerException when enabling cache statistics in Hibernate Cache

by Tomaž Cerar (Jira)

[ https://issues.jboss.org/browse/ISPN-10229?page=com.atlassian.jira.plugin... ] Tomaž Cerar commented on ISPN-10229: ------------------------------------ I can still reproduce this issue with 9.4.15. stacktrace is pretty much identical (with exception of running from spring boot app and not wildfly) > NullPointerException when enabling cache statistics in Hibernate Cache > ---------------------------------------------------------------------- > > Key: ISPN-10229 > URL: https://issues.jboss.org/browse/ISPN-10229 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 10.0.0.Beta3, 9.4.13.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 10.0.0.Beta4, 10.0.0.Final, 9.4.15.Final > > > Seems it'd only happen when clustered: > e.g. > {code} > ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (httpWorkerThreads task-1) ISPN000136: Error executing command ReadWriteKeyCommand, writing keys [com.dematic.wms.appdemo.caching.entity.CachedEntity#5]: java.lang.NullPointerException > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.lambda$updateStatisticsReadWrite$11(CacheMgmtInterceptor.java:331) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStatisticsReadWrite(CacheMgmtInterceptor.java:327) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitReadWriteKeyCommand(CacheMgmtInterceptor.java:351) > at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:207) > at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:207) > at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50) > at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234) > at org.infinispan@9.4.12.Final//org.infinispan.functional.impl.AbstractFunctionalMap.invokeAsync(AbstractFunctionalMap.java:127) > at org.infinispan@9.4.12.Final//org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56) > at org.infinispan.hibernate-cache@9.4.12.Final//org.infinispan.hibernate.cache.commons.access.TombstoneAccessDelegate.putFromLoad(TombstoneAccessDelegate.java:102) > at org.infinispan.hibernate-cache@9.4.12.Final//org.infinispan.hibernate.cache.v53.impl.ReadOnlyEntityDataAccess.putFromLoad(ReadOnlyEntityDataAccess.java:30) > at org.hibernate//org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:226) > at org.hibernate//org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:129) > at org.hibernate//org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:241) > at org.hibernate//org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:209) > at org.hibernate//org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:133) > at org.hibernate//org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122) > at org.hibernate//org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86) > at org.hibernate//org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:197) > at org.hibernate//org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4272) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:482) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:452) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:203) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:262) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:105) > at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:73) > at org.hibernate//org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1287) > at org.hibernate//org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:211) > at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.doLoad(SessionImpl.java:2923) > at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.lambda$load$1(SessionImpl.java:2904) > at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.perform(SessionImpl.java:2860) > at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2904) > at org.hibernate//org.hibernate.internal.SessionImpl.find(SessionImpl.java:3545) > at org.hibernate//org.hibernate.internal.SessionImpl.find(SessionImpl.java:3512) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10395) Remove GAV from infinispan-bom and distribution pom

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10395?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10395: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7135, https://github.com/infinispan/infinispan/pull/7144 (was: https://github.com/infinispan/infinispan/pull/7135) > Remove GAV from infinispan-bom and distribution pom > --------------------------------------------------- > > Key: ISPN-10395 > URL: https://issues.jboss.org/browse/ISPN-10395 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta4 > > > Remove the following GAV from infinispan-bom: > Sample/Test code: > {noformat} > org.infinispan.protostream:sample-domain-definition > org.infinispan.protostream:sample-domain-implementation > {noformat} > Integration test: > {noformat} > org.infinispan:infinispan-jcache-tck-runner > {noformat} > Removed, no longer built > {noformat} > org.infinispan:infinispan-remote > {noformat} > And remove the removed javadoc modules (embedded and remote) > EDIT > Removed uber jar > {noformat} > org.infinispan:infinispan-cli > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10029) Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10029?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10029: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Transactional invalidation cache with shared store prone to stale reads, even with FORCE_WRITE_LOCK > --------------------------------------------------------------------------------------------------- > > Key: ISPN-10029 > URL: https://issues.jboss.org/browse/ISPN-10029 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.6.Final, 9.4.11.Final, 10.0.0.Beta3 > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 10.0.0.Beta4, 9.3.7.Final, 9.4.14.Final > > Attachments: InvalidationLockingTest.java > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10395) Remove GAV from infinispan-bom and distribution pom

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10395?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10395: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta4 Resolution: Done > Remove GAV from infinispan-bom and distribution pom > --------------------------------------------------- > > Key: ISPN-10395 > URL: https://issues.jboss.org/browse/ISPN-10395 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta4 > > > Remove the following GAV from infinispan-bom: > Sample/Test code: > {noformat} > org.infinispan.protostream:sample-domain-definition > org.infinispan.protostream:sample-domain-implementation > {noformat} > Integration test: > {noformat} > org.infinispan:infinispan-jcache-tck-runner > {noformat} > Removed, no longer built > {noformat} > org.infinispan:infinispan-remote > {noformat} > And remove the removed javadoc modules (embedded and remote) > EDIT > Removed uber jar > {noformat} > org.infinispan:infinispan-cli > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10122) Unable to start application using Infinispan on Client/Server mode with JMX enabled

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10122?page=com.atlassian.jira.plugin... ] Katia Aresti updated ISPN-10122: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Unable to start application using Infinispan on Client/Server mode with JMX enabled > ----------------------------------------------------------------------------------- > > Key: ISPN-10122 > URL: https://issues.jboss.org/browse/ISPN-10122 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > A Spring-Boot application using Infinispan Client/Server with JMX enabled for the Infinispan Client won't start, unless you disable jmx spring.jmx.enabled=false. > Infinispan already registers a bean that is registered by Spring, so we get the following exception on start: > {code} > org.springframework.jmx.export.UnableToRegisterMBeanException: Unable to register MBean [org.infinispan.client.hotrod.RemoteCacheManager@1d67f4e9] with key 'remoteCacheManager'; nested exception is javax.management.InstanceAlreadyExistsException: MXBean already registered with name org.infinispan:type=HotRodClient,name=Default > at org.springframework.jmx.export.MBeanExporter.registerBeanNameOrInstance(MBeanExporter.java:625) ~[spring-context-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at org.springframework.jmx.export.MBeanExporter.lambda$registerBeans$2(MBeanExporter.java:551) ~[spring-context-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at java.base/java.util.HashMap.forEach(HashMap.java:1336) ~[na:na] > at org. > {code} > https://github.com/spring-projects/spring-boot/issues/16482 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10032: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6751, https://github.com/infinispan/infinispan/pull/7143 (was: https://github.com/infinispan/infinispan/pull/6751) > 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: Wolf-Dieter Fink > Priority: Critical > > 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)

5 years, 2 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10032?page=com.atlassian.jira.plugin... ] Tristan Tarrant reassigned ISPN-10032: -------------------------------------- Assignee: Tristan Tarrant (was: Wolf-Dieter Fink) > 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 > > 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)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10402) Implement undefine-counter operation for Hot Rod

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-10402: ---------------------------------- Summary: Implement undefine-counter operation for Hot Rod Key: ISPN-10402 URL: https://issues.jboss.org/browse/ISPN-10402 Project: Infinispan Issue Type: Feature Request Components: Clustered Counter, Hot Rod Reporter: Pedro Ruivo Assignee: Pedro Ruivo -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10390) Docs: Remove Non-working Examples from Getting Started

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10390?page=com.atlassian.jira.plugin... ] Donald Naro closed ISPN-10390. ------------------------------ > Docs: Remove Non-working Examples from Getting Started > ------------------------------------------------------ > > Key: ISPN-10390 > URL: https://issues.jboss.org/browse/ISPN-10390 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Beta3 > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Minor > Fix For: 10.0.0.Beta4 > > > https://infinispan.org/docs/10.0.x/getting_started/getting_started.html#s... uses uberjars > https://infinispan.org/docs/10.0.x/getting_started/getting_started.html#s... references a missing infinispantest.groovy -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2019