[JBoss JIRA] (ISPN-3473) CDI Cache interceptor tests are failing while running in Tomcat container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3473?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3473:
----------------------------------------
@Anna, can you try when ISPN-3316 is completed?
> CDI Cache interceptor tests are failing while running in Tomcat container
> -------------------------------------------------------------------------
>
> Key: ISPN-3473
> URL: https://issues.jboss.org/browse/ISPN-3473
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 6.0.0.Alpha3
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: 620
>
> There is a problem with Infinispan CDI interceptors under the Tomcat container.
> While running the infinispan/cdi-extension module's tests under the tomcat container, the following 2 related issues appear:
> 1) When the beans.xml contains the definition for the interceptors, as given below:
> {code}
> <beans xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
> <interceptors>
> <class>org.infinispan.jcache.annotation.CacheResultInterceptor</class>
> <class>org.infinispan.jcache.annotation.CachePutInterceptor</class>
> <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class>
> <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class>
> </interceptors>
> <alternatives>
> <class>org.infinispan.cdi.InjectedCacheResolver</class>
> </alternatives>
> </beans>
> {code}
> Then while the deployment on the container, the following exception is thrown:
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001416 Enabled interceptor class [<class>org.infinispan.jcache.annotation.CacheResultInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@7, <class>org.infinispan.jcache.annotation.CachePutInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@8, <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@9, <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class> in jar:file:/home/anna.manukyan/.jenkins/jobs/invm-tomcat/workspace/tomcat-server/jboss-ews-2.0/tomcat7/webapps/test/WEB-INF/lib/infinispan-jcache.jar!/META-INF/beans.xml@10, <class>org.infinispan.jcache.annotation.CacheResultInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@29, <class>org.infinispan.jcache.annotation.CachePutInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@30, <class>org.infinispan.jcache.annotation.CacheRemoveEntryInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@31, <class>org.infinispan.jcache.annotation.CacheRemoveAllInterceptor</class> in jndi:/localhost/test/WEB-INF/beans.xml@32] specified twice
> at org.jboss.weld.manager.Enabled.createMetadataMap(Enabled.java:123)
> at org.jboss.weld.manager.Enabled.<init>(Enabled.java:96)
> at org.jboss.weld.manager.Enabled.of(Enabled.java:79)
> at org.jboss.weld.bootstrap.BeanDeployment.<init>(BeanDeployment.java:114)
> at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:183)
> at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:152)
> at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:283)
> at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:151)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4791)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5285)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:963)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:537)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1468)
> at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1444)
> at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:677)
> at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:435)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:644)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> If there is no need declare the interceptors in the beans.xml (as far as I know it is necessary), then please let me know and ignore this case.
> 2) When the interceptors declaration is commented, then the interceptors doesn't work properly. So all tests located under the package org.infinispan.cdi.test.interceptor.* are failing with assertion errors.
> Please note that this behaviour is noticed for infinispan 6.0.0.Alpha3. It is not tried for the earlier versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3741) DistAsyncFuncTest / TopologyAwareDistAsyncFuncTest random failures
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3741:
----------------------------------
Summary: DistAsyncFuncTest / TopologyAwareDistAsyncFuncTest random failures
Key: ISPN-3741
URL: https://issues.jboss.org/browse/ISPN-3741
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Assignee: Mircea Markus
{{DistAsyncFuncTest.asyncWait()}} is not correct with the new non-tx locking scheme. The the originator (B) doesn't update the entry when it first executes the command, only when it executes it the second time (when it's forwarded back by C).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3740) AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3740:
----------------------------------
Summary: AbstractCacheTest.getDefaultClusteredCacheConfig() should not disable state transfer
Key: ISPN-3740
URL: https://issues.jboss.org/browse/ISPN-3740
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Assignee: Pedro Ruivo
Fix For: 7.0.0.Alpha1
The number of tests that use {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} and actually require state transfer to be disabled is insignificant: after commenting out the line that disables ST, I got 0 failures.
The Infinispan default is to have state transfer enabled, so developers naturally assume that state transfer is enabled all the time. It would be much clearer if {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} used the same defaults.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3738:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1032693
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3738:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1032693|https://bugzilla.redhat.com/show_bug.cgi?id=1032693]
Replicated TX cache with WSC, A, B are in cluster, C is joining
0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
2. C receives PrepareCommand and responds with no versions (it is not primary owner)
3. topology changes on B - primary ownership of K is transfered to C
4. B receives PrepareCommand, responds without K's version (it is not primary)
5. B forwards the Prepare to C as it sees that the command has lower topology ID
6. C responds to B's prepare with version of K
7. K version is not added to B's response, B responds to A
8. A finds out that topology has changed, forwards prepare to C
9. C responds to C's prepare with version of K
10. A receives C's response, but the versions are not added to transaction
11. A sends out CommitCommand missing version of K
12. all nodes record K=V without version as usual ImmortalCacheEntry
13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3316:
----------------------------------------
The problem, as mentioned in ISPN-3735 is that t injected cache resolver is not being used as alternative implementation for the cache resolver. This is because in CDI 1.0, alternatives can only be applied for injections in application, and not in libraries used by the application. Instead, I've created a paralell set of InjectCache*Interceptor classes for when InjectedCacheResolver is needed. I've tested the CDI quickstart with EAP 7.2 and it works fine.
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3739) HotRod: Add a statistic with the hit ratio of HotRod requests
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3739:
----------------------------------
Summary: HotRod: Add a statistic with the hit ratio of HotRod requests
Key: ISPN-3739
URL: https://issues.jboss.org/browse/ISPN-3739
Project: Infinispan
Issue Type: Feature Request
Components: Remote protocols
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Assignee: Galder Zamarreño
Fix For: 7.0.0.Final
The HotRod protocol is supposed to always direct requests to the primary owner of a key. It would be useful to expose a statistic with the number of requests that actually reach the primary owner as opposed to a backup owner (causing one extra RPC for non-tx write operations) or a non-owner (causing one extra RPC for both write and read operations).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3738:
---------------------------------
Summary: Entry version gets lost during topology change -> NPE
Key: ISPN-3738
URL: https://issues.jboss.org/browse/ISPN-3738
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.Final
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
Replicated TX cache with WSC, A, B are in cluster, C is joining
0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
2. C receives PrepareCommand and responds with no versions (it is not primary owner)
3. topology changes on B - primary ownership of K is transfered to C
4. B receives PrepareCommand, responds without K's version (it is not primary)
5. B forwards the Prepare to C as it sees that the command has lower topology ID
6. C responds to B's prepare with version of K
7. K version is *not* added to B's response, B responds to A
8. A finds out that topology has changed, forwards prepare to C
9. C responds to C's prepare with version of K
10. A receives C's response, but the versions are not added to transaction
11. A sends out CommitCommand missing version of K
12. all nodes record K=V without version as usual ImmortalCacheEntry
13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month