May 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5432) Updated jandex version used by ISPN server

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5432?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5432: ---------------------------------- Summary: Updated jandex version used by ISPN server (was: Updated jandex version) > Updated jandex version used by ISPN server > ------------------------------------------ > > Key: ISPN-5432 > URL: https://issues.jboss.org/browse/ISPN-5432 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Priority: Trivial > > Update {{jandex}} dependency to 1.2.1 [used by WildFly 8.2.0.Final|https://github.com/wildfly/wildfly/blob/8.2.0.Final/pom.xml#L179], which is current version which ISPN server depends on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5432) Updated jandex version

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-5432: ------------------------------------- Summary: Updated jandex version Key: ISPN-5432 URL: https://issues.jboss.org/browse/ISPN-5432 Project: Infinispan Issue Type: Task Components: Build process Reporter: Vojtech Juranek Assignee: Vojtech Juranek Priority: Trivial Update {{jandex}} dependency to 1.2.1 [used by WildFly 8.2.0.Final|https://github.com/wildfly/wildfly/blob/8.2.0.Final/pom.xml#L179], which is current version which ISPN server depends on. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5431) Move back jandex dependency

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-5431?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-5431: ---------------------------------- Description: Move back {{jandex}} dependency (removed by ISPN-5418) which is used by {{AbstractNamedFactoryExtensionProcessor}}. Removing it causes that Hot Rod remote listeners filter factories cannot be loaded (and causes {{HotRodRemoteCacheIT}} to fail, see e.g. [this CI build|http://ci.infinispan.org/viewLog.html?buildId=25903&tab=buildResult...]) (was: Move back {{jandex}} dependency which is used by {{AbstractNamedFactoryExtensionProcessor}}. Removing it causes that Hot Rod remote listeners filter factories cannot be loaded (and causes {{HotRodRemoteCacheIT}} to fail, see e.g. [this CI build|http://ci.infinispan.org/viewLog.html?buildId=25903&tab=buildResult... > Move back jandex dependency > --------------------------- > > Key: ISPN-5431 > URL: https://issues.jboss.org/browse/ISPN-5431 > Project: Infinispan > Issue Type: Bug > Components: Build process > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Priority: Trivial > > Move back {{jandex}} dependency (removed by ISPN-5418) which is used by {{AbstractNamedFactoryExtensionProcessor}}. Removing it causes that Hot Rod remote listeners filter factories cannot be loaded (and causes {{HotRodRemoteCacheIT}} to fail, see e.g. [this CI build|http://ci.infinispan.org/viewLog.html?buildId=25903&tab=buildResult...]) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5431) Move back jandex dependency

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-5431: ------------------------------------- Summary: Move back jandex dependency Key: ISPN-5431 URL: https://issues.jboss.org/browse/ISPN-5431 Project: Infinispan Issue Type: Bug Components: Build process Reporter: Vojtech Juranek Assignee: Vojtech Juranek Priority: Trivial Move back {{jandex}} dependency which is used by {{AbstractNamedFactoryExtensionProcessor}}. Removing it causes that Hot Rod remote listeners filter factories cannot be loaded (and causes {{HotRodRemoteCacheIT}} to fail, see e.g. [this CI build|http://ci.infinispan.org/viewLog.html?buildId=25903&tab=buildResult...]) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5403) NullPointerException on starting CacheStore

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5403?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5403: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 1196139|https://bugzilla.redhat.com/show_bug.cgi?id=1196139] from ON_QA to VERIFIED > NullPointerException on starting CacheStore > ------------------------------------------- > > Key: ISPN-5403 > URL: https://issues.jboss.org/browse/ISPN-5403 > Project: Infinispan > Issue Type: Bug > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > > Relevant stacktrace: > {code} > boss.infinispan.clustered.default: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1936) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31] > Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:171) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218) > at org.infinispan.CacheImpl.start(CacheImpl.java:779) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:587) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:542) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:104) > at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:101) > at org.infinispan.security.Security.doPrivileged(Security.java:76) > at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:48) > at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:109) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > ... 3 more > Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders > at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_31] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_31] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_31] > at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_31] > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > ... 23 more > Caused by: java.lang.NullPointerException > at org.infinispan.persistence.factory.CacheStoreFactoryRegistry.processStoreConfiguration(CacheStoreFactoryRegistry.java:48) > at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:529) > at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:114) > ... 28 more > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5430) Remove out of date C++ client docs

by Alan Field (JIRA)

Alan Field created ISPN-5430: -------------------------------- Summary: Remove out of date C++ client docs Key: ISPN-5430 URL: https://issues.jboss.org/browse/ISPN-5430 Project: Infinispan Issue Type: Bug Components: Documentation-Servers Reporter: Alan Field Someone pointed me to the following documentation page: http://infinispan.org/docs/hotrod-clients/cpp/ It has an error in the source code, but it is not in the {{documentation}} subdirectory of the infinispan project source tree. I could not find the text included in this page in the current documentation either. This set of docs needs to be removed from the website, and then this documentation needs to be folded into the current documentation set. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5429) Cluster CacheEventFilterConverter wrapping leads to double callbacks

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5429?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5429: ----------------------------------- Status: Open (was: New) > Cluster CacheEventFilterConverter wrapping leads to double callbacks > -------------------------------------------------------------------- > > Key: ISPN-5429 > URL: https://issues.jboss.org/browse/ISPN-5429 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.2.0.CR1, 7.1.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > This was spotted by Pierre Sutra from University of Neuchatel: > When a CacheEventFilterConverter is registered with remote event listeners, and running in a cluster, once the CacheEventFilterConverter instance is replicated, the notion that its both a filter AND converter is lost because BaseCacheEntryListenerInvocation's constructor determines that {{filterAndConvert}} is false. > The reason this happens is because after clustering it, the ClusterListenerReplicateCallable.call() wraps the {{filter}} into an {{AbstractCacheEventFilterConverter}} implementation, which does not keep the referential equality that BaseCacheEntryListenerInvocation's constructor checks. > A simple way to avoid this is to implement {{equals}} in the AbstractCacheEventFilterConverter implementation and use referential equality. Then, switching BaseCacheEntryListenerInvocation's constructors referential equality by a call to {{equals}} is enough to solve the issue. > The reason this bug was detected is because without a fix for it, the filter + converter gets two callbacks instead of one. I've added tests to verify that the number callbacks expected is the correct one. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5429) Cluster CacheEventFilterConverter wrapping leads to double callbacks

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5429?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5429: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3428 > Cluster CacheEventFilterConverter wrapping leads to double callbacks > -------------------------------------------------------------------- > > Key: ISPN-5429 > URL: https://issues.jboss.org/browse/ISPN-5429 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.2.0.CR1, 7.1.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > This was spotted by Pierre Sutra from University of Neuchatel: > When a CacheEventFilterConverter is registered with remote event listeners, and running in a cluster, once the CacheEventFilterConverter instance is replicated, the notion that its both a filter AND converter is lost because BaseCacheEntryListenerInvocation's constructor determines that {{filterAndConvert}} is false. > The reason this happens is because after clustering it, the ClusterListenerReplicateCallable.call() wraps the {{filter}} into an {{AbstractCacheEventFilterConverter}} implementation, which does not keep the referential equality that BaseCacheEntryListenerInvocation's constructor checks. > A simple way to avoid this is to implement {{equals}} in the AbstractCacheEventFilterConverter implementation and use referential equality. Then, switching BaseCacheEntryListenerInvocation's constructors referential equality by a call to {{equals}} is enough to solve the issue. > The reason this bug was detected is because without a fix for it, the filter + converter gets two callbacks instead of one. I've added tests to verify that the number callbacks expected is the correct one. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5429) Cluster CacheEventFilterConverter wrapping leads to double callbacks

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5429: -------------------------------------- Summary: Cluster CacheEventFilterConverter wrapping leads to double callbacks Key: ISPN-5429 URL: https://issues.jboss.org/browse/ISPN-5429 Project: Infinispan Issue Type: Bug Components: Listeners Affects Versions: 7.1.1.Final, 7.2.0.CR1 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.2.0.Final This was spotted by Pierre Sutra from University of Neuchatel: When a CacheEventFilterConverter is registered with remote event listeners, and running in a cluster, once the CacheEventFilterConverter instance is replicated, the notion that its both a filter AND converter is lost because BaseCacheEntryListenerInvocation's constructor determines that {{filterAndConvert}} is false. The reason this happens is because after clustering it, the ClusterListenerReplicateCallable.call() wraps the {{filter}} into an {{AbstractCacheEventFilterConverter}} implementation, which does not keep the referential equality that BaseCacheEntryListenerInvocation's constructor checks. A simple way to avoid this is to implement {{equals}} in the AbstractCacheEventFilterConverter implementation and use referential equality. Then, switching BaseCacheEntryListenerInvocation's constructors referential equality by a call to {{equals}} is enough to solve the issue. The reason this bug was detected is because without a fix for it, the filter + converter gets two callbacks instead of one. I've added tests to verify that the number callbacks expected is the correct one. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2015