October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10820) Upgrade to JGroups 4.1.6.Final

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10820?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10820: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Upgrade to JGroups 4.1.6.Final > ------------------------------ > > Key: ISPN-10820 > URL: https://issues.jboss.org/browse/ISPN-10820 > Project: Infinispan > Issue Type: Component Upgrade > Components: Dependency > Affects Versions: 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > [4.1.5.Final|https://issues.jboss.org/projects/JGRP/versions/12342765] added support for UDP and PING on Quarkus and fixed some issues with LOCAL_PING > [4.1.6.Final|https://issues.jboss.org/projects/JGRP/versions/12342864] fixes a recurring warning message from FD_ALL -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10821) Decrease GMS join_timeout and increase xPING num_discovery_runs

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10821?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10821: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Decrease GMS join_timeout and increase xPING num_discovery_runs > --------------------------------------------------------------- > > Key: ISPN-10821 > URL: https://issues.jboss.org/browse/ISPN-10821 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 9.4.16.Final, 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > Our default JGroups configurations have a GMS {{join_timeout="5000"}}, meaning the first node to start will always wait for 5 seconds before becoming coordinator. It should be safe to use the JGroups default of 2 seconds. > To make it even more safe, we could configure the discovery protocol's {{num_discovery_runs="3"}}, so that it makes multiple attempts to contact existing nodes during those 2 seconds of waiting. {{num_discovery_runs}} is only used for the initial discovery, so there's no danger of creating additional traffic while the node is up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10824) Hanged tests are ignored by Jenkins

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10824?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10824: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Hanged tests are ignored by Jenkins > ----------------------------------- > > Key: ISPN-10824 > URL: https://issues.jboss.org/browse/ISPN-10824 > Project: Infinispan > Issue Type: Bug > Components: Build, Test Suite - Core > Affects Versions: 9.4.16.Final, 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > ISPN-10161 was supposed to add a custom JUnit report in {{RunningTestsRegistry}} just before killing the JVM. Unfortunately it only calls {{TestSuiteProgress.fakeTestFailure()}}, which sounds like it should do it, but actually only writes a {{Test failed:}} messsage to the console, which Jenkins ignores. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10826) Fix GlobalXSiteAdminOpsTest failures

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10826?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10826: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Fix GlobalXSiteAdminOpsTest failures > ------------------------------------ > > Key: ISPN-10826 > URL: https://issues.jboss.org/browse/ISPN-10826 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 9.4.16.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 9.4.17.Final > > > Note. it only affects 9.4.x -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10829) CacheIgnoreManager unable to persist data

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10829?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10829: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > CacheIgnoreManager unable to persist data > ----------------------------------------- > > Key: ISPN-10829 > URL: https://issues.jboss.org/browse/ISPN-10829 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > The IgnoredCache test failures are due to a MarshallingException being thrown by the PersistenceMarshallerImpl. This is because no protostream marshaller is able to serialize the ConcurrentHashMap.KeySetView used to store values. Therefore, it's neccesssary to wrap this Set in a Java entity, so that a .proto message and associated marshaller can be generated by ProtoStream. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10718) Ensure protobuf metadata cache is predictably started when the cache manager has finished initializing

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10718?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10718: ------------------------------------------ Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #34, DataGrid Sprint #35) > Ensure protobuf metadata cache is predictably started when the cache manager has finished initializing > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-10718 > URL: https://issues.jboss.org/browse/ISPN-10718 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.Final > > > Casual code browsing led me to ProtobufMetadataCacheStartedTest where I see we actually assert that protobuf metadata cache is not started on cache manager start, it is actually started lazily, when first non-internal cache starts. And the code is written as if this is a (happy) accident. That's very dangerous. We should start it predictably, when the cache manager has finished startup. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10719) JCache: CacheManager.destroyCache should not remove internal caches

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10719?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10719: ------------------------------------------ Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #34, DataGrid Sprint #35) > JCache: CacheManager.destroyCache should not remove internal caches > ------------------------------------------------------------------- > > Key: ISPN-10719 > URL: https://issues.jboss.org/browse/ISPN-10719 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > > {{___protobuf_metadata}} is an internal cache, but it is also exposed to users -- including JCache users, who see it as a predefined cache. > Some JCache TCK tests try to remove all caches between test methods using > {{CacheManager.destroyCache()}}. By removing {{___protobuf_metadata}} they break {{ProtobufMetadataManagerImpl}} and don't allow the following tests to create any new caches: > {noformat} > [2019-10-01T07:11:13.651Z] [OK: 144, KO: 1, SKIP: 0] Test failed: CacheExpiryTest.testCacheStatisticsRemoveAllNoneExpired > [2019-10-01T07:11:13.651Z] org.infinispan.commons.CacheConfigurationException: ISPN000436: Cache '___protobuf_metadata' has been requested, but no cache configuration exists with that name and no default cache has been set for this container > [2019-10-01T07:11:13.651Z] at org.infinispan.configuration.ConfigurationManager.getConfiguration(ConfigurationManager.java:65) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:626) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:511) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:495) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:488) > [2019-10-01T07:11:13.651Z] at org.infinispan.query.remote.impl.SecurityActions.lambda$getUnwrappedCache$0(SecurityActions.java:43) > [2019-10-01T07:11:13.651Z] at org.infinispan.security.Security.doPrivileged(Security.java:47) > [2019-10-01T07:11:13.651Z] at org.infinispan.query.remote.impl.SecurityActions.doPrivileged(SecurityActions.java:30) > [2019-10-01T07:11:13.651Z] at org.infinispan.query.remote.impl.SecurityActions.getUnwrappedCache(SecurityActions.java:42) > [2019-10-01T07:11:13.651Z] at org.infinispan.query.remote.impl.ProtobufMetadataManagerImpl.addCacheDependency(ProtobufMetadataManagerImpl.java:68) > [2019-10-01T07:11:13.651Z] at org.infinispan.query.remote.impl.LifecycleManager.cacheStarting(LifecycleManager.java:215) > [2019-10-01T07:11:13.651Z] at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:223) > [2019-10-01T07:11:13.651Z] at org.infinispan.factories.ComponentRegistry.preStart(ComponentRegistry.java:213) > [2019-10-01T07:11:13.651Z] at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:238) > [2019-10-01T07:11:13.651Z] at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:203) > [2019-10-01T07:11:13.651Z] at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1082) > [2019-10-01T07:11:13.651Z] at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:512) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:682) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:626) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:511) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:495) > [2019-10-01T07:11:13.651Z] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:488) > [2019-10-01T07:11:13.651Z] at org.infinispan.jcache.embedded.JCacheManager.create(JCacheManager.java:149) > [2019-10-01T07:11:13.651Z] at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:93) > [2019-10-01T07:11:13.651Z] at org.jsr107.tck.expiry.CacheExpiryTest.testCacheStatisticsRemoveAllNoneExpired(CacheExpiryTest.java:163) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10721) jcache/tck-runner module should not unpack cache-tests

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10721?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10721: ------------------------------------------ Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #34, DataGrid Sprint #35) > jcache/tck-runner module should not unpack cache-tests > ------------------------------------------------------ > > Key: ISPN-10721 > URL: https://issues.jboss.org/browse/ISPN-10721 > Project: Infinispan > Issue Type: Bug > Components: JCache, Test Suite - Server > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > > The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests. > This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations: > {noformat} > [2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult > [2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between: > [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default], > [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default] > [2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26) > {noformat} > Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead: > {code:xml} > <dependenciesToScan> > <dependency>javax.cache:cache-tests</dependency> > </dependenciesToScan> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10743) Serializer should only serialize user defined AdvancedExternalizers

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10743?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10743: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Serializer should only serialize user defined AdvancedExternalizers > ------------------------------------------------------------------- > > Key: ISPN-10743 > URL: https://issues.jboss.org/browse/ISPN-10743 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 10.0.0.CR3 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > ISPN-10727 Is caused because the Serialization configuration is deemed to have been modified by a user in the test setup. However, the classes being serialized are the internal Externalizers that are defined in various modules ModuleLifecycle implementations and are of no significance to the user, as they will always be applied regardless of the xml configuration. Therefore, we should hide all internal Externalizer classes from the user. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10749) Invalidation mode needs a proper key partitioner

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10749?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10749: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Invalidation mode needs a proper key partitioner > ------------------------------------------------ > > Key: ISPN-10749 > URL: https://issues.jboss.org/browse/ISPN-10749 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.16.Final, 10.0.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.1.0.Final > > > Caches in invalidation mode used to do everything on the local node and only broadcast an invalidation command to all the members. ISPN-10029 changed this, and now transactional invalidation caches acquire locks for affected keys on the primary owners. > Unfortunately {{KeyPartitionerFactory}} constructs a {{SingleSegmentKeyPartitioner}} in invalidation mode, so there is only one primary owner for all the keys. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 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 October 2019