[JBoss JIRA] (ISPN-10868) Default whitelist should allow primitives, arrays and ArrayList
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10868?page=com.atlassian.jira.plugin... ]
Ryan Emerson reopened ISPN-10868:
---------------------------------
> Default whitelist should allow primitives, arrays and ArrayList
> ---------------------------------------------------------------
>
> Key: ISPN-10868
> URL: https://issues.jboss.org/browse/ISPN-10868
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.0.Final
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Java serialization whitelist should include primitive wrapper classes and arrays types, if only because it's tedious to specify all of them in the configuration.
> There's a similar argument for adding {{java.util.ArrayList}} to the default whitelist, especially to use as keys, because {{Object[]}} keys do not work with {{OBJECT}} storage ({{equals()}} and {{hashCode()}} are wrong). I'm not convinced yet, because applications eventually want to use a custom key class, and POCs can get away with converting to {{String}} and concatenating.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10911) HotRodMultiMapOperations random failures
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-10911?page=com.atlassian.jira.plugin... ]
Katia Aresti updated ISPN-10911:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> HotRodMultiMapOperations random failures
> ----------------------------------------
>
> Key: ISPN-10911
> URL: https://issues.jboss.org/browse/ISPN-10911
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.0.Beta1
>
>
> Multimap operations are asynchronous, and the test doesn't wait for the writes to finish before starting a get. Multimap and Infinispan in general do not guarantee that asynchronous operations started from the same thread run in any particular order.
> {noformat}
> 09:07:49,325 ERROR (testng-HotRodMultiMapOperations:[]) [TestSuiteProgress] Test failed: HotRodMultiMapOperations.testMultiMap
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.junit.Assert.fail(Assert.java:88) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.failNotEquals(Assert.java:834) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.assertEquals(Assert.java:645) ~[junit-4.12.jar:4.12]
> at org.junit.Assert.assertEquals(Assert.java:631) ~[junit-4.12.jar:4.12]
> at org.infinispan.server.functional.HotRodMultiMapOperations.testMultiMap(HotRodMultiMapOperations.java:41) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10868) Default whitelist should allow primitives, arrays and ArrayList
by Katia Aresti (Jira)
[ https://issues.jboss.org/browse/ISPN-10868?page=com.atlassian.jira.plugin... ]
Katia Aresti updated ISPN-10868:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Default whitelist should allow primitives, arrays and ArrayList
> ---------------------------------------------------------------
>
> Key: ISPN-10868
> URL: https://issues.jboss.org/browse/ISPN-10868
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.0.Final
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Java serialization whitelist should include primitive wrapper classes and arrays types, if only because it's tedious to specify all of them in the configuration.
> There's a similar argument for adding {{java.util.ArrayList}} to the default whitelist, especially to use as keys, because {{Object[]}} keys do not work with {{OBJECT}} storage ({{equals()}} and {{hashCode()}} are wrong). I'm not convinced yet, because applications eventually want to use a custom key class, and POCs can get away with converting to {{String}} and concatenating.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10912) HotRod server retries CheckAddressTask indefinitely during shutdown
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10912?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10912:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/7550 (was: https://github.com/infinispan/infinispan/pull/7545)
> HotRod server retries CheckAddressTask indefinitely during shutdown
> -------------------------------------------------------------------
>
> Key: ISPN-10912
> URL: https://issues.jboss.org/browse/ISPN-10912
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> Normally retrying to add the local address to the topology cache is a good idea, but {{IllegalLifecycleStateException}} should be handled differently.
> {noformat}
> 09:09:03,471 DEBUG (remote-thread--p11-t2:[]) [HotRodServer] Error re-adding address to topology cache, retrying
> org.infinispan.commons.CacheException: org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container.
> at org.infinispan.server.hotrod.HotRodServer$ReAddMyAddressListener.lambda$recursionTopologyChanged$0(HotRodServer.java:678) ~[infinispan-server-hotrod-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.impl.LocalClusterExecutor.lambda$submitConsumer$3(LocalClusterExecutor.java:78) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) ~[?:?]
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) ~[?:?]
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) ~[?:?]
> at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) ~[?:?]
> at org.infinispan.manager.impl.LocalClusterExecutor.lambda$localInvocation$6(LocalClusterExecutor.java:97) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:215) [infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container.
> at org.infinispan.manager.DefaultCacheManager.assertIsNotTerminated(DefaultCacheManager.java:1070) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:502) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:498) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:491) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.getCache(AbstractDelegatingEmbeddedCacheManager.java:196) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.impl.UnwrappingEmbeddedCacheManager.getCache(UnwrappingEmbeddedCacheManager.java:25) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.server.hotrod.CheckAddressTask.apply(HotRodServer.java:725) ~[infinispan-server-hotrod-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.server.hotrod.CheckAddressTask.apply(HotRodServer.java:712) ~[infinispan-server-hotrod-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> at org.infinispan.manager.impl.LocalClusterExecutor.lambda$localInvocation$6(LocalClusterExecutor.java:94) ~[infinispan-core-10.1.0-SNAPSHOT.jar:10.1.0-SNAPSHOT]
> ... 4 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-7002) NPE in DelegatingQuery.java:42 when deployed in Wildfly 10.1.0.Final
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/ISPN-7002?page=com.atlassian.jira.plugin.... ]
Nistor Adrian commented on ISPN-7002:
-------------------------------------
Any chance to update to latest infinispan? 8.2.x is old and not maintained and it seems what you are looking for does not even exist on maven central. No Idea why it's not there.
> NPE in DelegatingQuery.java:42 when deployed in Wildfly 10.1.0.Final
> --------------------------------------------------------------------
>
> Key: ISPN-7002
> URL: https://issues.jboss.org/browse/ISPN-7002
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.4.Final
> Environment: Fedora 24
> openjdk version "1.8.0_102"
> OpenJDK Runtime Environment (build 1.8.0_102-b14)
> OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)
> Reporter: Pavol Loffay
> Assignee: Nistor Adrian
> Priority: Blocker
>
> Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
> Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
> Application source code: https://github.com/pavolloffay/infinispan-wildfly10
> Error for infinispan 8.2.0.Final in Wildfly 10.0.0.Final:
> {code:java}
> 15:29:25,025 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:629)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:93)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:38)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:45)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> ... 32 more
> {code}
> Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
> {code:java}
> 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 42 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10915) CompletionStages.continueOnExecutor() does not complete the future on rejection
by Dan Berindei (Jira)
Dan Berindei created ISPN-10915:
-----------------------------------
Summary: CompletionStages.continueOnExecutor() does not complete the future on rejection
Key: ISPN-10915
URL: https://issues.jboss.org/browse/ISPN-10915
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 10.0.1.Final, 9.4.16.Final
Reporter: Dan Berindei
Assignee: Will Burns
Fix For: 10.1.0.Beta1
{{CompletionStages.continueOnExecutor()}} returns a {{CompletableFuture}} that is supposed to complete after the supplied action has run on the supplied executor. If the executor rejects the action, e.g. because it was stopped, the {{CompletableFuture}} never completes.
E.g. {{JGroupsTransport.receiveClusterView()}} indirectly uses {{CompletionStages.continueOnExecutor()}}, and it blocks view handling forever if a view is received after the async operations executor has been shut down. In turn this blocks all further view processing and the cache manager shutdown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10915) CompletionStages.continueOnExecutor() does not complete the future on rejection
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10915?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10915:
--------------------------------
Status: Open (was: New)
> CompletionStages.continueOnExecutor() does not complete the future on rejection
> -------------------------------------------------------------------------------
>
> Key: ISPN-10915
> URL: https://issues.jboss.org/browse/ISPN-10915
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.1.Final
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> {{CompletionStages.continueOnExecutor()}} returns a {{CompletableFuture}} that is supposed to complete after the supplied action has run on the supplied executor. If the executor rejects the action, e.g. because it was stopped, the {{CompletableFuture}} never completes.
> E.g. {{JGroupsTransport.receiveClusterView()}} indirectly uses {{CompletionStages.continueOnExecutor()}}, and it blocks view handling forever if a view is received after the async operations executor has been shut down. In turn this blocks all further view processing and the cache manager shutdown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10868) Default whitelist should allow primitives, arrays and ArrayList
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10868?page=com.atlassian.jira.plugin... ]
Ryan Emerson updated ISPN-10868:
--------------------------------
Status: Open (was: New)
> Default whitelist should allow primitives, arrays and ArrayList
> ---------------------------------------------------------------
>
> Key: ISPN-10868
> URL: https://issues.jboss.org/browse/ISPN-10868
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.0.Final
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Java serialization whitelist should include primitive wrapper classes and arrays types, if only because it's tedious to specify all of them in the configuration.
> There's a similar argument for adding {{java.util.ArrayList}} to the default whitelist, especially to use as keys, because {{Object[]}} keys do not work with {{OBJECT}} storage ({{equals()}} and {{hashCode()}} are wrong). I'm not convinced yet, because applications eventually want to use a custom key class, and POCs can get away with converting to {{String}} and concatenating.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-10868) Default whitelist should allow primitives, arrays and ArrayList
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10868?page=com.atlassian.jira.plugin... ]
Ryan Emerson updated ISPN-10868:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7549
> Default whitelist should allow primitives, arrays and ArrayList
> ---------------------------------------------------------------
>
> Key: ISPN-10868
> URL: https://issues.jboss.org/browse/ISPN-10868
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.4.16.Final, 10.0.0.Final
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Java serialization whitelist should include primitive wrapper classes and arrays types, if only because it's tedious to specify all of them in the configuration.
> There's a similar argument for adding {{java.util.ArrayList}} to the default whitelist, especially to use as keys, because {{Object[]}} keys do not work with {{OBJECT}} storage ({{equals()}} and {{hashCode()}} are wrong). I'm not convinced yet, because applications eventually want to use a custom key class, and POCs can get away with converting to {{String}} and concatenating.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months