[JBoss JIRA] (ISPN-10229) NullPointerException when enabling cache statistics in Hibernate Cache
by Galder Zamarreño (Jira)
[ https://issues.jboss.org/browse/ISPN-10229?page=com.atlassian.jira.plugin... ]
Galder Zamarreño updated ISPN-10229:
------------------------------------
Fix Version/s: 10.0.0.Beta4
10.0.0.Final
9.4.14.Final
> NullPointerException when enabling cache statistics in Hibernate Cache
> ----------------------------------------------------------------------
>
> Key: ISPN-10229
> URL: https://issues.jboss.org/browse/ISPN-10229
> Project: Infinispan
> Issue Type: Bug
> Components: Hibernate Cache
> Affects Versions: 10.0.0.Beta3, 9.4.13.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Major
> Fix For: 10.0.0.Beta4, 10.0.0.Final, 9.4.14.Final
>
>
> Seems it'd only happen when clustered:
> e.g.
> {code}
> ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (httpWorkerThreads task-1) ISPN000136: Error executing command ReadWriteKeyCommand, writing keys [com.dematic.wms.appdemo.caching.entity.CachedEntity#5]: java.lang.NullPointerException
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.lambda$updateStatisticsReadWrite$11(CacheMgmtInterceptor.java:331)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStatisticsReadWrite(CacheMgmtInterceptor.java:327)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitReadWriteKeyCommand(CacheMgmtInterceptor.java:351)
> at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:207)
> at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:207)
> at org.infinispan@9.4.12.Final//org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:113)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> at org.infinispan@9.4.12.Final//org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan@9.4.12.Final//org.infinispan.functional.impl.AbstractFunctionalMap.invokeAsync(AbstractFunctionalMap.java:127)
> at org.infinispan@9.4.12.Final//org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
> at org.infinispan.hibernate-cache@9.4.12.Final//org.infinispan.hibernate.cache.commons.access.TombstoneAccessDelegate.putFromLoad(TombstoneAccessDelegate.java:102)
> at org.infinispan.hibernate-cache@9.4.12.Final//org.infinispan.hibernate.cache.v53.impl.ReadOnlyEntityDataAccess.putFromLoad(ReadOnlyEntityDataAccess.java:30)
> at org.hibernate//org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:226)
> at org.hibernate//org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:129)
> at org.hibernate//org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:241)
> at org.hibernate//org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:209)
> at org.hibernate//org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:133)
> at org.hibernate//org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122)
> at org.hibernate//org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86)
> at org.hibernate//org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:197)
> at org.hibernate//org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4272)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:482)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:452)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:203)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:262)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:105)
> at org.hibernate//org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:73)
> at org.hibernate//org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1287)
> at org.hibernate//org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:211)
> at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.doLoad(SessionImpl.java:2923)
> at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.lambda$load$1(SessionImpl.java:2904)
> at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.perform(SessionImpl.java:2860)
> at org.hibernate//org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2904)
> at org.hibernate//org.hibernate.internal.SessionImpl.find(SessionImpl.java:3545)
> at org.hibernate//org.hibernate.internal.SessionImpl.find(SessionImpl.java:3512)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10232) PersistenceManagerImpl stop waits forever for active publishers to finish
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10232?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10232:
--------------------------------
Status: Open (was: New)
> PersistenceManagerImpl stop waits forever for active publishers to finish
> -------------------------------------------------------------------------
>
> Key: ISPN-10232
> URL: https://issues.jboss.org/browse/ISPN-10232
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.Beta3, 9.4.13.Final
> Reporter: Dan Berindei
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> {{PersistenceManagerImpl.stop()}} acquires all the permits of {{publisherSemaphore}} to make sure there is no ongoing iteration. But there is no timeout, so if the application is slowly going through all the entries in a huge cache it could block cache stop for a very long time.
> What's more, when a publisher finishes, the stop thread and other threads trying to start a new publisher have the same priority, and if the new publisher acquires a permit stop will have to wait for it to finish.
> We should limit the amount of time we wait for iterations to finish, similar to how {{TransactionTable}} only waits for ongoing transactions to finish for {{transaction.cacheStopTimeout}} millis. Ideally we would move {{cacheStopTimeout}} out of the transaction configuration and use it everywhere we could wait for user threads to finish doing their work before stopping.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-9979) AbstractComponentRegistry.stop() can hang if called concurrently
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9979?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9979:
-------------------------------
Fix Version/s: 10.0.0.Beta4
> AbstractComponentRegistry.stop() can hang if called concurrently
> ----------------------------------------------------------------
>
> Key: ISPN-9979
> URL: https://issues.jboss.org/browse/ISPN-9979
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.3.Final
> Reporter: Philippe Julien
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4
>
>
> I believe that there is a bug in org.infinispan.factories.AbstractComponentRegistry.stop()
> Our Wildfly 15 nodes often hang on shutdown on the following:
> {noformat}
> "MSC service thread 1-2" #37 prio=5 os_prio=0 tid=0x0000000003807000 nid=0xf32d in Object.wait() [0x00007f0012c6f000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000005cc795fa8> (a org.infinispan.factories.ComponentRegistry)
> at java.lang.Object.wait(Object.java:502)
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:359)
> - locked <0x00000005cc795fa8> (a org.infinispan.factories.ComponentRegistry)
> at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1159)
> at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1124)
> at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520)
> at org.infinispan.manager.DefaultCacheManager.terminate(DefaultCacheManager.java:734)
> at org.infinispan.manager.DefaultCacheManager.stopCaches(DefaultCacheManager.java:786)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:762)
> at org.jboss.as.clustering.infinispan.subsystem.CacheContainerServiceConfigurator.accept(CacheContainerServiceConfigurator.java:114)
> at org.jboss.as.clustering.infinispan.subsystem.CacheContainerServiceConfigurator.accept(CacheContainerServiceConfigurator.java:70)
> at org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1794)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1763)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There are no other threads that are working with 0x00000005cc795fa8 in the thread dump.
> I checked in a heap dump and the 0x00000005cc795fa8 org.infinispan.factories.ComponentRegistry object state is TERMINATED.
> I think that the finally block of AbstractComponentRegistry.stop() is missing a notifyAll().
> Shouldn't this:
> {code}
> ...
> } finally {
> synchronized (this) {
> state = ComponentStatus.TERMINATED;
> }
> }
> {code}
> Be:
> {code}
> ...
> } finally {
> synchronized (this) {
> state = ComponentStatus.TERMINATED;
> notifyAll();
> }
> }
> {code}
> This way, if two thread try to stop the same cache, the one that wins will notify the one that is waiting letting its stop complete.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10040:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/6816, https://github.com/infinispan/infinispan/pull/6817, https://github.com/infinispan/infinispan/pull/6962 (was: https://github.com/infinispan/infinispan/pull/6816, https://github.com/infinispan/infinispan/pull/6817)
> Embedded and server thread pool defaults should be the same
> -----------------------------------------------------------
>
> Key: ISPN-10040
> URL: https://issues.jboss.org/browse/ISPN-10040
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.2.11.Final, 9.4.9.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.14.Final
>
>
> Embedded:
> {code:java}
> DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200);
> DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0);
> {code}
> Server:
> {code:java}
> REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000),
> {code}
> Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10228) Server licenses should be in docs/licenses/licenses.xml
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10228?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10228:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Server licenses should be in docs/licenses/licenses.xml
> -------------------------------------------------------
>
> Key: ISPN-10228
> URL: https://issues.jboss.org/browse/ISPN-10228
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 10.0.0.Beta3, 9.4.13.Final
> Reporter: Prajakta Deshmukh
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.14.Final
>
>
> While Comparing distributions such as library, server, maven repository with current (7.3.1.CR2) and the previous build( 7.3.0-1) it fails with Missing Licenses : LICENSE NOT FOUND
> Steps to Reproduce :
> 1) Script run : /jdg-qe/scripts/initial-testing/initial-testing.sh
> 2) JDG_VERSION_LABEL = 7.3.1.CR2
> 3) JDG_VERSION_LABEL_PREVIOUS_BUILD = 7.3.0-1
> Fails with below missing licenses :================================================================
> Distribution Check fails with below Missing Licenses :
> [LICENSE NOT FOUND] com.googlecode.javaewah:JavaEWAH:1.1.6
> [LICENSE NOT FOUND] com.jcraft:jsch:0.1.54
> [LICENSE NOT FOUND] com.jcraft:jsch:0.1.54.redhat-00001
> [LICENSE NOT FOUND] com.jcraft:jzlib:1.1.1
> [LICENSE NOT FOUND] io.fabric8:agent-bond-agent:1.0.2.redhat-1
> [LICENSE NOT FOUND] io.netty:netty-transport-native-unix-common:4.1.28.Final-redhat-00001
> [LICENSE NOT FOUND] io.prometheus.jmx:jmx_prometheus_javaagent:0.3.1.redhat-00001
> [LICENSE NOT FOUND] io.reactivex.rxjava2:rxjava:2.2.4.redhat-00003
> [LICENSE NOT FOUND] javax.cache:cache-api:1.1.0.redhat-1
> [LICENSE NOT FOUND] javax.inject:javax.inject:1.0.0.redhat-6
> [LICENSE NOT FOUND] org.aesh:aesh-extensions:1.6.0.redhat-00001
> [LICENSE NOT FOUND] org.aesh:aesh-readline:1.10.0.redhat-00001
> [LICENSE NOT FOUND] org.aesh:aesh:1.7.0.redhat-00001 ----> (and packed as: aesh-readline-1.10.0.redhat-00001.jar )
> [LICENSE NOT FOUND] org.eclipse.jgit:org.eclipse.jgit:5.0.2.201807311906-r-redhat-00001
> [LICENSE NOT FOUND] org.fusesource.jansi:jansi:1.16.0.redhat-4
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-clustering-common:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-clustering-marshalling-api:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-clustering-marshalling-spi:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-clustering-service:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-ee:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-iiop-openjdk:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-naming:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-security:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.eap:wildfly-transactions:7.2.0.GA-redhat-00005
> [LICENSE NOT FOUND] org.jboss.spec.javax.annotation:jboss-annotations-api_1.3_spec:1.0.1.Final-redhat-1
> [LICENSE NOT FOUND] org.jboss.spec.javax.el:jboss-el-api_3.0_spec:1.0.12.Final-redhat-00001
> [LICENSE NOT FOUND] org.projectodd.vdx:vdx-core:1.1.6.redhat-1
> [LICENSE NOT FOUND] org.projectodd.vdx:vdx-wildfly:1.1.6.redhat-1
> [LICENSE NOT FOUND] org.reactivestreams:reactive-streams:1.0.2.redhat-1
> [LICENSE NOT FOUND] org.wildfly.client:wildfly-client-config:1.0.1.Final-redhat-00001
> [LICENSE NOT FOUND] org.wildfly.core:wildfly-core-management-client:6.0.11.Final-redhat-00001
> [LICENSE NOT FOUND] org.wildfly.core:wildfly-embedded:6.0.11.Final-redhat-00001
> [LICENSE NOT FOUND] org.wildfly.security.elytron-web:undertow-server:1.2.3.Final-redhat-00001
> [LICENSE NOT FOUND] org.wildfly.transaction:wildfly-transaction-client:1.1.2.Final-redhat-1
> [LICENSE NOT FOUND] org.wildfly.wildfly-http-client:wildfly-http-client-common:1.0.12.Final-redhat-1
> [LICENSE NOT FOUND] org.wildfly.wildfly-http-client:wildfly-http-naming-client:1.0.12.Final-redhat-1
> [LICENSE NOT FOUND] org.wildfly.wildfly-http-client:wildfly-http-transaction-client:1.0.12.Final-redhat-1
> [LICENSE NOT FOUND] org.wildfly:wildfly-naming-client:1.0.9.Final-redhat-1
> [LICENSE NOT FOUND] antlr:antlr:2.7.7.redhat-7 ----> (and packed as: antlr-bsd.txt )
> [LICENSE NOT FOUND] com.thoughtworks.xstream:xstream:1.4.10.redhat-1 ----> (and packed as: xstream-bsd.txt )
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10040:
-------------------------------
Status: Pull Request Sent (was: Reopened)
> Embedded and server thread pool defaults should be the same
> -----------------------------------------------------------
>
> Key: ISPN-10040
> URL: https://issues.jboss.org/browse/ISPN-10040
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.2.11.Final, 9.4.9.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.14.Final
>
>
> Embedded:
> {code:java}
> DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200);
> DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0);
> {code}
> Server:
> {code:java}
> REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000),
> {code}
> Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10040:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Embedded and server thread pool defaults should be the same
> -----------------------------------------------------------
>
> Key: ISPN-10040
> URL: https://issues.jboss.org/browse/ISPN-10040
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.2.11.Final, 9.4.9.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta4, 9.4.14.Final
>
>
> Embedded:
> {code:java}
> DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200);
> DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0);
> {code}
> Server:
> {code:java}
> REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000),
> {code}
> Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (ISPN-10235) Allow SpringRemoteCacheManager create a cache in runtime with the default or a provided template
by Diego Lovison (Jira)
Diego Lovison created ISPN-10235:
------------------------------------
Summary: Allow SpringRemoteCacheManager create a cache in runtime with the default or a provided template
Key: ISPN-10235
URL: https://issues.jboss.org/browse/ISPN-10235
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 10.0.0.Beta3
Reporter: Diego Lovison
When working in a Spring app we can provide a cache name and Spring will create that cache in Runtime. When using Remote Infinispan Spring Cache Support the exception will throw
{noformat}
org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.server.hotrod.CacheNotFoundException
{noformat}
This is because SpringRemoteCacheManager support only getCache
{code:java}
public SpringCache getCache(String name) {
RemoteCache<Object, Object> nativeCache = this.nativeCacheManager.getCache(name);
return new SpringCache(nativeCache, this.readTimeout, this.writeTimeout);
}
{code}
We could allow the developer specify a boolean value like: createRemoteCacheInRuntime=true and defaultRemoteCacheTemplate=myTemplate
In this case when adding @Cacheable("books") the books cache will be created based on the specified arguments
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months