[JBoss JIRA] (ISPN-10815) Javadoc missing jboss-marshalling dependency
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10815?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10815:
------------------------------------------
Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35)
> Javadoc missing jboss-marshalling dependency
> --------------------------------------------
>
> Key: ISPN-10815
> URL: https://issues.jboss.org/browse/ISPN-10815
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Core
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Caused by ISPN-10591 which removed the {{infinispan-jboss-marshalling}} dependency from the persistence-remote jar, which was transitively pulling in the dependency to the documentation module.
> The solution is to add an explicit dependency on {{infinispan-jboss-marshalling}} to the javadoc pom.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (ISPN-10819) GracefulShutdownRestartIT Failure
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10819?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10819:
------------------------------------------
Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35)
> GracefulShutdownRestartIT Failure
> ---------------------------------
>
> Key: ISPN-10819
> URL: https://issues.jboss.org/browse/ISPN-10819
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> The GlobalMarshaller is unable to marshall {{Server.ShutdownRunnable}} as it does not have an externalizer defined. This wasn't an issue when jboss-marshalling was used in the Server as the class was marshalled via Serialization, however now that the default user marshaller is Protostream based this is not possible. The solution is to enable the GlobalMarshaller to be able to marshall the class directly. This can be achieved by defining an Externalizer for the class.
> {code:java}_emphasized text_
> [0] STDOUT: 19:05:14,244 WARN [org.infinispan.PERSISTENCE] (SINGLE_PORT-ServerIO-7-2) ISPN000559: Cannot marshall 'class org.infinispan.server.Server$ShutdownRunnable': java.lang.IllegalArgumentException: No marshaller registered for Java type org.infinispan.server.Server$ShutdownRunnable
> [0] STDOUT: at org.infinispan.protostream.impl.SerializationContextImpl.getMarshallerDelegate(SerializationContextImpl.java:279)
> [0] STDOUT: at org.infinispan.protostream.WrappedMessage.writeMessage(WrappedMessage.java:240)
> [0] STDOUT: at org.infinispan.protostream.ProtobufUtil.toWrappedStream(ProtobufUtil.java:196)
> [0] STDOUT: at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.objectToBuffer(PersistenceMarshallerImpl.java:157)
> [0] STDOUT: at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.objectToByteBuffer(PersistenceMarshallerImpl.java:137)
> [0] STDOUT: at org.infinispan.marshall.persistence.impl.PersistenceMarshallerImpl.objectToByteBuffer(PersistenceMarshallerImpl.java:145)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeRawUnknown(GlobalMarshaller.java:638)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeUnknown(GlobalMarshaller.java:627)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeUnknown(GlobalMarshaller.java:618)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeNonNullableObject(GlobalMarshaller.java:384)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeNullableObject(GlobalMarshaller.java:352)
> [0] STDOUT: at org.infinispan.marshall.core.BytesObjectOutput.writeObject(BytesObjectOutput.java:26)
> [0] STDOUT: at org.infinispan.manager.impl.ReplicableManagerFunctionCommand.writeTo(ReplicableManagerFunctionCommand.java:54)
> [0] STDOUT: at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:70)
> [0] STDOUT: at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeObject(ReplicableCommandExternalizer.java:66)
> [0] STDOUT: at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeObject(ReplicableCommandExternalizer.java:54)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeInternal(GlobalMarshaller.java:656)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeNonNullableObject(GlobalMarshaller.java:371)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeNullableObject(GlobalMarshaller.java:352)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:181)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:174)
> [0] STDOUT: at org.infinispan.marshall.core.GlobalMarshaller.objectToBuffer(GlobalMarshaller.java:302)+underlined text+
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[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)
6 years, 5 months
[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)
6 years, 5 months
[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)
6 years, 5 months
[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)
6 years, 5 months
[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)
6 years, 5 months
[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)
6 years, 5 months