[JBoss JIRA] (ISPN-10696) Cluster Expiration reaper limits parallel expirations too much
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10696?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10696:
-----------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR3)
> Cluster Expiration reaper limits parallel expirations too much
> --------------------------------------------------------------
>
> Key: ISPN-10696
> URL: https://issues.jboss.org/browse/ISPN-10696
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 10.0.0.CR2
> Reporter: Will Burns
> Priority: Major
> Fix For: 10.0.0.Final, 9.4.17.Final
>
>
> The expiration reaper today currently limits the expiration to only allow 5 pending expiration commands at once. It also doesn't submit more expirations until those 5 complete. We should do the following changes:
> # Increase the limit, possibly to 100?
> # Allow for extra expiration commands to be invoked as the others are complete, instead of waiting for all of them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10707) Jcache: loaded entries should use ExpiryPolicy.getExpiryForCreation()
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10707?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10707:
-----------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR3)
> Jcache: loaded entries should use ExpiryPolicy.getExpiryForCreation()
> ---------------------------------------------------------------------
>
> Key: ISPN-10707
> URL: https://issues.jboss.org/browse/ISPN-10707
> Project: Infinispan
> Issue Type: Bug
> Components: Core, JCache
> Affects Versions: 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> {{MVCCEntry.isLoaded()}} is not used in the core, but JCache uses it do decide whether to call {{ExpiryPolicy.getExpiryForCreation()}} or {{ExpiryPolicy.getExpiryForAccess()}}.
> ISPN-8086 accidentally removed the {{ReadCommittedEntry}} implementation along with {{CacheEntry.isLoaded()}}, but the {{CacheExpiryTest}} test failure got ignored because Jenkins ignores the TCK test suite results (ISPN-10379).
> {noformat}
> [OK: 14, KO: 1, SKIP: 0] Test failed: CacheExpiryTest.invokeAllReadThroughEnabledGetOnNonExistentEntry
> java.lang.AssertionError:
> Expected: is <0>
> but: was <5>
> at org.jsr107.tck.expiry.CacheExpiryTest.invokeAllReadThroughEnabledGetOnNonExistentEntry(CacheExpiryTest.java:1202)
> [OK: 15, KO: 2, SKIP: 0] Test failed: CacheExpiryTest.invokeGetValueWithReadThroughForNonExistentEntryShouldCallGetExpiryForCreatedEntry
> java.lang.AssertionError:
> Expected: is <0>
> but: was <1>
> at org.jsr107.tck.expiry.CacheExpiryTest.invokeGetValueWithReadThroughForNonExistentEntryShouldCallGetExpiryForCreatedEntry(CacheExpiryTest.java:1110)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10718) Ensure protobuf metadata cache is predictably started when the cache manager has finished initializing
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10718?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10718:
-----------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR3)
> 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, 6 months
[JBoss JIRA] (ISPN-10719) JCache: CacheManager.destroyCache should not remove internal caches
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10719?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10719:
-----------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR3)
> 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, 6 months
[JBoss JIRA] (ISPN-10723) JMX registration cleanup
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10723?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10723:
-----------------------------------
Fix Version/s: 10.0.0.Final
(was: 10.0.0.CR3)
> JMX registration cleanup
> ------------------------
>
> Key: ISPN-10723
> URL: https://issues.jboss.org/browse/ISPN-10723
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.CR1
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> - all jmx registration should happen via CacheManagerJmxRegistration/CacheJmxRegistration - we should not have other classes using JmxUtil.buildJmxDomain
> - there are very few legitimate direct usages of JmxUtil.lookupMBeanServer; all else must go
> - some registrations are not currently ResourceDMBeans; these need to be converted
> - use of registerExternalMBean should be converted to registerMBean
> - avoid performing the unregistration manually. Components registered with registerMBean will be unregistered automatically
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10591) Remove jboss-marshalling and make Protostream the default user marshaller
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10591?page=com.atlassian.jira.plugin... ]
Ryan Emerson updated ISPN-10591:
--------------------------------
Summary: Remove jboss-marshalling and make Protostream the default user marshaller (was: Remove jboss-marshallign and make Protostream the default user marshaller)
> Remove jboss-marshalling and make Protostream the default user marshaller
> -------------------------------------------------------------------------
>
> Key: ISPN-10591
> URL: https://issues.jboss.org/browse/ISPN-10591
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 10.0.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> Protostream should be used as the default marshaller for user types unless a user explicitly provides a custom marshaller via {{SerializationConfiguration.marshaller}}.
> This requires that all of our testsuite is also updated to provide protostream pojos and that the `infinispan-jboss-marshalling` dependency is removed from all possible sub-modules. Most notably:
> * core
> * query
> * server
> * client
> This will require various integration tests to also be updated to reflect the new behaviour, as the APPLICATION_JBOSS_MARSHALLING media type will not be available to the client/server by default.
> In order for a user to utilise jboss-marshalling on the client side, it's necessary for the `infinispan-jboss-marshalling` jar to be added to the classpath. Furthermore, if APPLICATION_OBJECT storage is desired on the server and jboss-marshalling is utilised on the client, it's also necessary for the dependency to be added to the server. In order to verify that this functionality works as expected, it's necessary for a `integrationtests/jboss-marshalling` sub-module to be created in order to test these scenarios.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10591) Remove jboss-marshallign and make Protostream the default user marshaller
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10591?page=com.atlassian.jira.plugin... ]
Ryan Emerson updated ISPN-10591:
--------------------------------
Summary: Remove jboss-marshallign and make Protostream the default user marshaller (was: Make Protostream the default user marshaller)
> Remove jboss-marshallign and make Protostream the default user marshaller
> -------------------------------------------------------------------------
>
> Key: ISPN-10591
> URL: https://issues.jboss.org/browse/ISPN-10591
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 10.0.0.CR1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> Protostream should be used as the default marshaller for user types unless a user explicitly provides a custom marshaller via {{SerializationConfiguration.marshaller}}.
> This requires that all of our testsuite is also updated to provide protostream pojos and that the `infinispan-jboss-marshalling` dependency is removed from all possible sub-modules. Most notably:
> * core
> * query
> * server
> * client
> This will require various integration tests to also be updated to reflect the new behaviour, as the APPLICATION_JBOSS_MARSHALLING media type will not be available to the client/server by default.
> In order for a user to utilise jboss-marshalling on the client side, it's necessary for the `infinispan-jboss-marshalling` jar to be added to the classpath. Furthermore, if APPLICATION_OBJECT storage is desired on the server and jboss-marshalling is utilised on the client, it's also necessary for the dependency to be added to the server. In order to verify that this functionality works as expected, it's necessary for a `integrationtests/jboss-marshalling` sub-module to be created in order to test these scenarios.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months