[JBoss JIRA] (ISPN-10173) infinispan-springX-remote doesn't allow to disable cached session with a configuration property
by Jose Antonio Iñigo (Jira)
Jose Antonio Iñigo created ISPN-10173:
-----------------------------------------
Summary: infinispan-springX-remote doesn't allow to disable cached session with a configuration property
Key: ISPN-10173
URL: https://issues.jboss.org/browse/ISPN-10173
Project: Infinispan
Issue Type: Feature Request
Components: Spring Integration
Reporter: Jose Antonio Iñigo
I am using infinispan-spring4-remote in a Spring Boot 1.5 project. This declares the EnableInfinispanRemoteHttpSession in its main class.
I don't want to use the distribuited cache for http session externalization in unit/integration tests launched with JUnit. The problem is the application crashes when launching the tests:
```
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.infinispan.spring.provider.SpringRemoteCacheManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1491)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1102)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1064)
at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
... 63 more
```
EnableInfinispanRemoteHttpSession imports InfinispanRemoteHttpSessionConfiguration and the latter doesn't have any way (@ConditionalOnProperty for instance) that would allow us to disable that behaviour.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10173) infinispan-springX-remote doesn't allow to disable cached session with a configuration property
by Jose Antonio Iñigo (Jira)
[ https://issues.jboss.org/browse/ISPN-10173?page=com.atlassian.jira.plugin... ]
Jose Antonio Iñigo updated ISPN-10173:
--------------------------------------
Description:
I am using infinispan-spring4-remote in a Spring Boot 1.5 project. This declares the EnableInfinispanRemoteHttpSession in its main class.
I don't want to use the distribuited cache for http session externalization in unit/integration tests launched with JUnit. The problem is the application crashes when launching the tests:
{code:java}
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.infinispan.spring.provider.SpringRemoteCacheManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1491)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1102)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1064)
at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
... 63 more
{code}
EnableInfinispanRemoteHttpSession imports InfinispanRemoteHttpSessionConfiguration and the latter doesn't have any way (@ConditionalOnProperty for instance) that would allow us to disable that behaviour.
was:
I am using infinispan-spring4-remote in a Spring Boot 1.5 project. This declares the EnableInfinispanRemoteHttpSession in its main class.
I don't want to use the distribuited cache for http session externalization in unit/integration tests launched with JUnit. The problem is the application crashes when launching the tests:
```
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.infinispan.spring.provider.SpringRemoteCacheManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1491)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1102)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1064)
at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
... 63 more
```
EnableInfinispanRemoteHttpSession imports InfinispanRemoteHttpSessionConfiguration and the latter doesn't have any way (@ConditionalOnProperty for instance) that would allow us to disable that behaviour.
> infinispan-springX-remote doesn't allow to disable cached session with a configuration property
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-10173
> URL: https://issues.jboss.org/browse/ISPN-10173
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Reporter: Jose Antonio Iñigo
> Priority: Major
>
> I am using infinispan-spring4-remote in a Spring Boot 1.5 project. This declares the EnableInfinispanRemoteHttpSession in its main class.
> I don't want to use the distribuited cache for http session externalization in unit/integration tests launched with JUnit. The problem is the application crashes when launching the tests:
> {code:java}
> Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.infinispan.spring.provider.SpringRemoteCacheManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1491)
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1102)
> at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1064)
> at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
> at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
> ... 63 more
> {code}
> EnableInfinispanRemoteHttpSession imports InfinispanRemoteHttpSessionConfiguration and the latter doesn't have any way (@ConditionalOnProperty for instance) that would allow us to disable that behaviour.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10171) Spring Cache sync locking does not work
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10171?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10171:
-----------------------------------
Status: Pull Request Sent (was: Open)
> Spring Cache sync locking does not work
> ---------------------------------------
>
> Key: ISPN-10171
> URL: https://issues.jboss.org/browse/ISPN-10171
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 9.4.11.Final, 10.0.0.Beta4
> Environment: > mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-11.0.1.jdk/Contents/Home
> Default locale: en_NL, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> Reporter: Rens van Leeuwen
> Assignee: Katia Aresti
> Priority: Major
>
> With ISPN-7224/https://github.com/infinispan/infinispan/pull/5262, an implementation was written to support a synchronous get that implements Spring Cache's {{@Cacheable(sync = true)}}.
> That seems to work well in isolation, but not in an integrated way. By that I mean, that the implementation of {{SpringCache}} maintains its own {{ReentrantLock}}s in each instance.
> Zooming out a bit, this is part of the call stack when the {{SpringCache}} instance is looked up during handling the {{@Cacheable(sync = true)}} annotation:
> {noformat}
> CacheInterceptor.invoke(MethodInvocation) (org.springframework.cache.interceptor)
> CacheAspectSupport.execute(CacheOperationInvoker, Object, Method, Object[]) (org.springframework.cache.interceptor)
> CacheOperationContexts in CacheAspectSupport.CacheOperationContexts(Collection<? extends CacheOperation>, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheAspectSupport.getOperationContext(CacheOperation, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheOperationContext in CacheAspectSupport.CacheOperationContext(CacheOperationMetadata, Object[], Object) (org.springframework.cache.interceptor)
> CacheAspectSupport.getCaches(CacheOperationInvocationContext<CacheOperation>, CacheResolver) (org.springframework.cache.interceptor)
> AbstractCacheResolver.resolveCaches(CacheOperationInvocationContext<?>) (org.springframework.cache.interceptor)
> ----->> SpringEmbeddedCacheManager.getCache(String) (org.infinispan.spring.embedded.provider)
> SpringCache.SpringCache(BasicCache) (org.infinispan.spring.common.provider)
> SpringCache.SpringCache(BasicCache, long, long) (org.infinispan.spring.common.provider)
> {noformat}
> The problem with this is, that for each turn the interceptor handles the request a *new instance* of the {{SpringCache}} is made in the {{SpringEmbeddedCacheManager}}, rendering the use of the {{ReentrantLock}} mechanism useless to a certain extent, because multiple threads accessing the {{@Cacheable(sync = true)}} method will each have their own {{SpringCache}} and corresponding {{ReentrantLock}}.
> In turn, there is no locking at all, and each thread will be executing the (assumed to be) expensive code that is intended to be cached.
> --
> I'm intending to write a patch for this, but this would be the first time I commit to an open source project (bear with me ;)). I'll try to provide a pull request for this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10171) Spring Cache sync locking does not work
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10171?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10171:
-----------------------------------
Status: Open (was: New)
> Spring Cache sync locking does not work
> ---------------------------------------
>
> Key: ISPN-10171
> URL: https://issues.jboss.org/browse/ISPN-10171
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 9.4.11.Final, 10.0.0.Beta4
> Environment: > mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-11.0.1.jdk/Contents/Home
> Default locale: en_NL, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> Reporter: Rens van Leeuwen
> Assignee: Katia Aresti
> Priority: Major
>
> With ISPN-7224/https://github.com/infinispan/infinispan/pull/5262, an implementation was written to support a synchronous get that implements Spring Cache's {{@Cacheable(sync = true)}}.
> That seems to work well in isolation, but not in an integrated way. By that I mean, that the implementation of {{SpringCache}} maintains its own {{ReentrantLock}}s in each instance.
> Zooming out a bit, this is part of the call stack when the {{SpringCache}} instance is looked up during handling the {{@Cacheable(sync = true)}} annotation:
> {noformat}
> CacheInterceptor.invoke(MethodInvocation) (org.springframework.cache.interceptor)
> CacheAspectSupport.execute(CacheOperationInvoker, Object, Method, Object[]) (org.springframework.cache.interceptor)
> CacheOperationContexts in CacheAspectSupport.CacheOperationContexts(Collection<? extends CacheOperation>, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheAspectSupport.getOperationContext(CacheOperation, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheOperationContext in CacheAspectSupport.CacheOperationContext(CacheOperationMetadata, Object[], Object) (org.springframework.cache.interceptor)
> CacheAspectSupport.getCaches(CacheOperationInvocationContext<CacheOperation>, CacheResolver) (org.springframework.cache.interceptor)
> AbstractCacheResolver.resolveCaches(CacheOperationInvocationContext<?>) (org.springframework.cache.interceptor)
> ----->> SpringEmbeddedCacheManager.getCache(String) (org.infinispan.spring.embedded.provider)
> SpringCache.SpringCache(BasicCache) (org.infinispan.spring.common.provider)
> SpringCache.SpringCache(BasicCache, long, long) (org.infinispan.spring.common.provider)
> {noformat}
> The problem with this is, that for each turn the interceptor handles the request a *new instance* of the {{SpringCache}} is made in the {{SpringEmbeddedCacheManager}}, rendering the use of the {{ReentrantLock}} mechanism useless to a certain extent, because multiple threads accessing the {{@Cacheable(sync = true)}} method will each have their own {{SpringCache}} and corresponding {{ReentrantLock}}.
> In turn, there is no locking at all, and each thread will be executing the (assumed to be) expensive code that is intended to be cached.
> --
> I'm intending to write a patch for this, but this would be the first time I commit to an open source project (bear with me ;)). I'll try to provide a pull request for this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10171) Spring Cache sync locking does not work
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10171?page=com.atlassian.jira.plugin... ]
Tristan Tarrant reassigned ISPN-10171:
--------------------------------------
Assignee: Katia Aresti
> Spring Cache sync locking does not work
> ---------------------------------------
>
> Key: ISPN-10171
> URL: https://issues.jboss.org/browse/ISPN-10171
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 9.4.11.Final, 10.0.0.Beta4
> Environment: > mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 11.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-11.0.1.jdk/Contents/Home
> Default locale: en_NL, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
> Reporter: Rens van Leeuwen
> Assignee: Katia Aresti
> Priority: Major
>
> With ISPN-7224/https://github.com/infinispan/infinispan/pull/5262, an implementation was written to support a synchronous get that implements Spring Cache's {{@Cacheable(sync = true)}}.
> That seems to work well in isolation, but not in an integrated way. By that I mean, that the implementation of {{SpringCache}} maintains its own {{ReentrantLock}}s in each instance.
> Zooming out a bit, this is part of the call stack when the {{SpringCache}} instance is looked up during handling the {{@Cacheable(sync = true)}} annotation:
> {noformat}
> CacheInterceptor.invoke(MethodInvocation) (org.springframework.cache.interceptor)
> CacheAspectSupport.execute(CacheOperationInvoker, Object, Method, Object[]) (org.springframework.cache.interceptor)
> CacheOperationContexts in CacheAspectSupport.CacheOperationContexts(Collection<? extends CacheOperation>, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheAspectSupport.getOperationContext(CacheOperation, Method, Object[], Object, Class<?>) (org.springframework.cache.interceptor)
> CacheOperationContext in CacheAspectSupport.CacheOperationContext(CacheOperationMetadata, Object[], Object) (org.springframework.cache.interceptor)
> CacheAspectSupport.getCaches(CacheOperationInvocationContext<CacheOperation>, CacheResolver) (org.springframework.cache.interceptor)
> AbstractCacheResolver.resolveCaches(CacheOperationInvocationContext<?>) (org.springframework.cache.interceptor)
> ----->> SpringEmbeddedCacheManager.getCache(String) (org.infinispan.spring.embedded.provider)
> SpringCache.SpringCache(BasicCache) (org.infinispan.spring.common.provider)
> SpringCache.SpringCache(BasicCache, long, long) (org.infinispan.spring.common.provider)
> {noformat}
> The problem with this is, that for each turn the interceptor handles the request a *new instance* of the {{SpringCache}} is made in the {{SpringEmbeddedCacheManager}}, rendering the use of the {{ReentrantLock}} mechanism useless to a certain extent, because multiple threads accessing the {{@Cacheable(sync = true)}} method will each have their own {{SpringCache}} and corresponding {{ReentrantLock}}.
> In turn, there is no locking at all, and each thread will be executing the (assumed to be) expensive code that is intended to be cached.
> --
> I'm intending to write a patch for this, but this would be the first time I commit to an open source project (bear with me ;)). I'll try to provide a pull request for this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10106) Fix thread leaks in JUnit modules
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10106?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10106:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/6857, https://github.com/infinispan/infinispan/pull/6858, https://github.com/infinispan/infinispan/pull/6875, https://github.com/infinispan/infinispan/pull/6877, https://github.com/infinispan/infinispan/pull/6894 (was: https://github.com/infinispan/infinispan/pull/6857, https://github.com/infinispan/infinispan/pull/6858, https://github.com/infinispan/infinispan/pull/6875, https://github.com/infinispan/infinispan/pull/6877)
> Fix thread leaks in JUnit modules
> ---------------------------------
>
> Key: ISPN-10106
> URL: https://issues.jboss.org/browse/ISPN-10106
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.4.11.Final, 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4, 9.4.13.Final
>
>
> ISPN-9863 added a thread leak checker, but even with all the recent improvements, leaks in JUnit modules are not reported as test failures.
> Because Surefire ignores failures in JUnit configuration methods and listeners, the only sign of a leak is an error message in the console output:
> {noformat}
> [2019-03-28T17:33:54.119Z] org.apache.maven.surefire.booter.SurefireBooterForkException: ExecutionException There was an error in the forked process
> [2019-03-28T17:33:54.119Z] Test mechanism :: Leaked threads:
> [2019-03-28T17:33:54.119Z] {pool-7-thread-1: possible sources [UNKNOWN]},
> [2019-03-28T17:33:54.119Z] {management-client-thread 1-1: possible sources [UNKNOWN]}
> {noformat}
> And in a dump file:
> {noformat}
> [2019-03-28T18:23:39.501Z] ./integrationtests/security-it/target/failsafe-reports/2019-03-28T17-28-10_213-jvmRun1.dump
> [2019-03-28T18:23:39.501Z] # Created at 2019-03-28T17:29:25.623
> [2019-03-28T18:23:39.501Z] org.apache.maven.surefire.testset.TestSetFailedException: Test mechanism :: Leaked threads:
> [2019-03-28T18:23:39.501Z] {pool-7-thread-1: possible sources [UNKNOWN]},
> [2019-03-28T18:23:39.501Z] {management-client-thread 1-1: possible sources [UNKNOWN]}
> [2019-03-28T18:23:39.501Z] at org.apache.maven.surefire.common.junit4.JUnit4RunListener.rethrowAnyTestMechanismFailures(JUnit4RunListener.java:223)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (ISPN-10106) Fix thread leaks in JUnit modules
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10106?page=com.atlassian.jira.plugin... ]
Dan Berindei reopened ISPN-10106:
---------------------------------
I missed some leaks in server/integration/testsuite
> Fix thread leaks in JUnit modules
> ---------------------------------
>
> Key: ISPN-10106
> URL: https://issues.jboss.org/browse/ISPN-10106
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.4.11.Final, 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4, 9.4.13.Final
>
>
> ISPN-9863 added a thread leak checker, but even with all the recent improvements, leaks in JUnit modules are not reported as test failures.
> Because Surefire ignores failures in JUnit configuration methods and listeners, the only sign of a leak is an error message in the console output:
> {noformat}
> [2019-03-28T17:33:54.119Z] org.apache.maven.surefire.booter.SurefireBooterForkException: ExecutionException There was an error in the forked process
> [2019-03-28T17:33:54.119Z] Test mechanism :: Leaked threads:
> [2019-03-28T17:33:54.119Z] {pool-7-thread-1: possible sources [UNKNOWN]},
> [2019-03-28T17:33:54.119Z] {management-client-thread 1-1: possible sources [UNKNOWN]}
> {noformat}
> And in a dump file:
> {noformat}
> [2019-03-28T18:23:39.501Z] ./integrationtests/security-it/target/failsafe-reports/2019-03-28T17-28-10_213-jvmRun1.dump
> [2019-03-28T18:23:39.501Z] # Created at 2019-03-28T17:29:25.623
> [2019-03-28T18:23:39.501Z] org.apache.maven.surefire.testset.TestSetFailedException: Test mechanism :: Leaked threads:
> [2019-03-28T18:23:39.501Z] {pool-7-thread-1: possible sources [UNKNOWN]},
> [2019-03-28T18:23:39.501Z] {management-client-thread 1-1: possible sources [UNKNOWN]}
> [2019-03-28T18:23:39.501Z] at org.apache.maven.surefire.common.junit4.JUnit4RunListener.rethrowAnyTestMechanismFailures(JUnit4RunListener.java:223)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months