[JBoss JIRA] (ISPN-10349) PersistenceManager.addSegments may never complete
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10349?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-10349:
------------------------------
Sprint: DataGrid Sprint #30
> PersistenceManager.addSegments may never complete
> -------------------------------------------------
>
> Key: ISPN-10349
> URL: https://issues.jboss.org/browse/ISPN-10349
> Project: Infinispan
> Issue Type: Bug
> Components: Core
&…
[View More]gt; Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4
>
>
> {{PersistenceManager.addSegments}} returns a {{CompletionStage}} which should be completed on a persistence executor thread. If the persistence executor was already stopped at the time {{addSegments()}} was called, however, the {{CompletionStage}} is never completed.
> This doesn't prevent the cache manager from stopping, but it causes a thread leak because a transport thread waits forever on the {{CompletionStage}}. E.g.
> {noformat}
> 16:57:06,128 TRACE (testng-Test:[]) [BasicComponentRegistryImpl] Changed status of org.infinispan.executors.persistence to STOPPED
> 16:57:06,150 TRACE (transport-thread-Test-NodeB-p2059-t4:[Topology-testCache]) [PersistenceManagerImpl] Adding segments for id 584
> # no other mention of id 584
> 17:15:17,300 ERROR [TestSuiteProgress] Test failed: SharedStoreInvalidationDuringRehashTest.ThreadLeakChecker
> java.lang.RuntimeException: Leaked thread transport-thread-SharedStoreInvalidationDuringRehashTest-NodeB-p2059-t4
> at jdk.internal.misc.Unsafe.park(Native Method) ~[?:?]
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) ~[?:?]
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1798) ~[?:?]
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128) ~[?:?]
> at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1868) ~[?:?]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021) ~[?:?]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:110) ~[classes/:?]
> at org.infinispan.util.concurrent.CompletionStages.join(CompletionStages.java:73) ~[classes/:?]
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:306) ~[classes/:?]
> at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.onTopologyUpdate(ScatteredStateConsumerImpl.java:102) ~[classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-10266) Spring Cache doesn't remove the cache or update the cache configuration
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-10266?page=com.atlassian.jira.plugin... ]
Katia Aresti updated ISPN-10266:
--------------------------------
Sprint: DataGrid Sprint #30
> Spring Cache doesn't remove the cache or update the cache configuration
> -----------------------------------------------------------------------
>
> Key: ISPN-10266
> URL: https://issues.jboss.org/browse/ISPN-10266
> Project: Infinispan
> …
[View More]Issue Type: Bug
> Affects Versions: 9.4.14.Final
> Reporter: Diego Lovison
> Assignee: Katia Aresti
> Priority: Major
>
> After ISPN-10171, the Spring Cache doesn't remove the cache or update the cache configuration.
> I am expecting the cache to be null once it was removed from remote cache manager.
> {code:java}
> @Test
> public final void getCacheShouldReturnNullItWasChangedByRemoteCacheManager() {
> // Given
> objectUnderTest = new SpringRemoteCacheManager(remoteCacheManager);
> // When
> objectUnderTest.getCache(TEST_CACHE_NAME);
> remoteCacheManager.administration().removeCache(TEST_CACHE_NAME);
> // Then
> assertNull(objectUnderTest.getCache(TEST_CACHE_NAME));
> }
> {code}
> I am expecting a different instance of the cache once the configuration was changed.
> {code:java}
> @Test
> public final void getCacheShouldReturnDiffInstanceItWasChangedByRemoteCacheManager() {
> // Given
> objectUnderTest = new SpringRemoteCacheManager(remoteCacheManager);
> // When
> final SpringCache firstObtainedSpringCache = objectUnderTest.getCache(TEST_CACHE_NAME);
> remoteCacheManager.administration().removeCache(TEST_CACHE_NAME);
> remoteCacheManager.administration().createCache(TEST_CACHE_NAME, cacheManager.getDefaultCacheConfiguration());
> // Then
> final SpringCache secondObtainedSpringCache = objectUnderTest.getCache(TEST_CACHE_NAME);
> assertNotSame(
> "getCache() shouldn't have the same SpringCache instance for the same name because the config was changed",
> firstObtainedSpringCache, secondObtainedSpringCache);
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-10354) Remove jboss-marshalling dependency from core
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-10354:
-----------------------------------
Summary: Remove jboss-marshalling dependency from core
Key: ISPN-10354
URL: https://issues.jboss.org/browse/ISPN-10354
Project: Infinispan
Issue Type: Sub-task
Components: Core, Marshalling
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Currently the core module has a hard dependency on jboss-marshalling regardless of what …
[View More]user marshaller is used, therefore we should make the necessary abstractions to remove this. This work compliments ISPN-9263 as it should not be necessary to have a jboss-marshalling jar on the classpath when utilising protostream marshalling. Furthermore, jboss-marshalling is not compatible with Quarkus, therefore this step is required in order for Infinispan embedded to be readily consumed via a Quarkus extension.
Removing jboss-marshalling will result in Serializable user types no longer being marshallable as default, therefore we should introduce a `infinispan-jboss-marshalling` jar that users can continue to utilise jboss-marshalling if they wish. Furthermore, it should also be possible for users to utilise {{JavaSerializationMarshaller}} as the configured user marshaller.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9620:
-------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #29, DataGrid Sprint #30 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #29)
> Rolling Upgrade Marshaller Changes
> ----------------------------------
>
> Key: ISPN-9620
> …
[View More] URL: https://issues.jboss.org/browse/ISPN-9620
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Loaders and Stores
> Affects Versions: 9.4.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-8535:
-----------------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #30 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31)
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/…
[View More]browse/ISPN-8535
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
> * Stop individual servers and the full cluster
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
[View Less]
5 years, 7 months