[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3316:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> 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
> Reporter: Anna Manukyan
> Assignee: Mircea Markus
> Labels: 620
>
> 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
12 years, 5 months
[JBoss JIRA] (ISPN-3404) ClusterCacheLoader NPE when ClusteredGetCommand response value is null
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3404?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3404:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> ClusterCacheLoader NPE when ClusteredGetCommand response value is null
> ----------------------------------------------------------------------
>
> Key: ISPN-3404
> URL: https://issues.jboss.org/browse/ISPN-3404
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Alpha2
> Reporter: Tomas Sykora
> Assignee: Pedro Ruivo
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
> Attachments: clusterCacheLoaderNullPointerResponseValueError.txt, server1DR2.log, server2DR2.log
>
>
> We found this issue in DR2 (Alpha2). In Alpha1 this was ok.
> Our internal test:
> {code:title=Bar.java|borderStyle=solid}
> @Test
> public void testLazyLoadingWhenStateTransferDisabled() throws Exception {
> controller.start(CONTAINER1);
> mc = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint()
> .getPort());
> mc.set("k1", "v1");
> mc.set("k2", "v2");
> assertEquals("v1", mc.get("k1"));
> assertEquals("v2", mc.get("k2"));
> assertEquals(2, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries());
> controller.start(CONTAINER2);
> mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint()
> .getPort());
> assertEquals(2, server2.getDefaultCacheManager().getClusterSize());
> //state-transfer = false -> no entries in the newly joined node
> assertEquals(0, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries());
> assertEquals("v1", mc2.get("k1")); //lazily load the entries
> assertEquals("v2", mc2.get("k2"));
> assertEquals(2, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries());
> mc2.set("k3", "v3"); // THIS IS FAILING HERE
> assertEquals(3, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries());
> assertEquals(3, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries());
> controller.kill(CONTAINER2);
> controller.kill(CONTAINER1);
> }
> {code}
> *mc2.set("k3", "v3"); = put into memcached cache, is throwing an exception: see in attachment.*
> You can see MemcachedHelper class here: https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests....
> I also include trace logs for both memcached jdg servers if they can be useful.
> ---------------
> I was able to replicate the same error in Infinispan test suite for Rest endpoint. It was enough to start 2 REST nodes and issue 1 put resulting into the same error.
> {code:title=Bar.java|borderStyle=solid}
> ConfigurationBuilder cfgBuilder = AbstractCacheTest.getDefaultClusteredCacheConfig(CacheMode.REPL_SYNC, false);
> cfgBuilder.clustering().hash().numOwners(1);
> cfgBuilder.clustering().stateTransfer().fetchInMemoryState(false);
> cfgBuilder.clustering().stateTransfer().timeout(20000);
> cfgBuilder.loaders().addClusterCacheLoader().remoteCallTimeout(60000);
> RestServerConfigurationBuilder restCfgBuilder = new RestServerConfigurationBuilder();
> addServer("1", 8890, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build());
> addServer("2", 8891, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build());
> startServers();
> ......
> PutMethod put = new PutMethod(PATH1 + "key1");
> put.setRequestEntity(new StringRequestEntity("value1", "application/text", null));
> call(put);
> assertEquals(put.getStatusCode(), HttpServletResponse.SC_OK);
> put.releaseConnection();
> {code}
> This scenario is different from aforementioned JDG internal test suite one but I expect this should be ok and should be performed without any problems.
>
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3613) Stored entries are deleted from table in rebalance
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3613?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3613:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> Stored entries are deleted from table in rebalance
> --------------------------------------------------
>
> Key: ISPN-3613
> URL: https://issues.jboss.org/browse/ISPN-3613
> Project: Infinispan
> Issue Type: Bug
> Reporter: Mircea Markus
> Assignee: William Burns
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Description of problem:
> When passivation value is false, stored entries are deleted from table in rebalance.
> clustered.xml
> ------------
> <distributed-cache name="myCache" mode="SYNC" start="EAGER">
> <locking isolation="READ_COMMITTED" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LIRS" max-entries="10000"/>
> <string-keyed-jdbc-store datasource="java:jboss/datasources/InfinispanDS" passivation="false" preload="true" purge="false" shared="true" fetch-state="false">
> ...
> Version-Release number of selected component (if applicable):
> JDG 6.1
> How reproducible:
> I will attache the clustered.xml and trace logs.
> Steps to Reproduce:
> 1.start node1
> 2.put 300 entries
> 3.start node2
> check entries:
> select count(*) from table;
> 300
> 4.start node3
> check entries:
> select count(*) from table;
> 0
> Actual results:
> In step 4, number of entries are 0 in DB table.
> Expected results:
> In step 4, number of entries are 300 in DB table.
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3552) HotRod Rolling Upgrades NPE when disabling cache store on target node
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3552?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3552:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> HotRod Rolling Upgrades NPE when disabling cache store on target node
> ---------------------------------------------------------------------
>
> Key: ISPN-3552
> URL: https://issues.jboss.org/browse/ISPN-3552
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Beta1
> Reporter: Tomas Sykora
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2
>
> Attachments: standalone-source-node-rollups52-dist.xml, standalone-target-node-rollups-dist.xml
>
>
> After Tristan's fix for https://issues.jboss.org/browse/ISPN-3183 we can move successfully through recordKnownGlobalKeyset and synchronizeData operations.
> However, when we want to issue disconnectSource operation on target node, it is failing with given error:
> javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1058)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:225)
> 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)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> ... 9 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.manager.PersistenceManagerImpl.disableStore(PersistenceManagerImpl.java:253)
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.disconnectSource(HotRodTargetMigrator.java:101)
> at org.infinispan.upgrade.RollingUpgradeManager.disconnectSource(RollingUpgradeManager.java:71)
> ... 14 more
> Short input from Tristan: "problem is that after removing the store, it determines there are no more stores left so it tries to remove the loader/writer interceptors which for some reason are missing"
>
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3321) NPE in MapReduceTask reduce phase
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3321?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3321:
------------------------------
Labels: 620 (was: jdg62GAblocker)
> NPE in MapReduceTask reduce phase
> ---------------------------------
>
> Key: ISPN-3321
> URL: https://issues.jboss.org/browse/ISPN-3321
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.3.0.Final
> Reporter: Alan Field
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR1
>
>
> During the execution of a MapReduce word count job with 6 nodes, the following NPE is thrown:
> 11:19:37,870 ERROR [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-2) Exception executing command
> java.lang.NullPointerException
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.reduce(MapReduceManagerImpl.java:153)
> at org.infinispan.commands.read.ReduceCommand.perform(ReduceCommand.java:88)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:122)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:68)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:194)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> The full log is here - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/afield@REDHAT.COM/m...'s%20jobs/job/jdg-radargun-mapreduce-test/181/console-edg-perf06/
> Looking at the code to see if I can figure out what happened.
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3598) ISPN testsuite fails for RHEL 5, 6 && IBM JDK6
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3598?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3598:
------------------------------
Labels: 620 (was: jdg62GAblocker testsuite_stability)
> ISPN testsuite fails for RHEL 5,6 && IBM JDK6
> ---------------------------------------------
>
> Key: ISPN-3598
> URL: https://issues.jboss.org/browse/ISPN-3598
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Beta1
> Environment: RHEL{5, 6} && IBM JDK6
> Reporter: Anna Manukyan
> Assignee: William Burns
> Labels: 620
> Fix For: 6.0.0.CR2
>
> Attachments: ibm6_infinispan_failure_rhel5_x32.log, ibm6_infinispan_failure_rhel5_x64.log, ibm6_infinispan_failure_rhel6_x32.log, ibm6_infinispan_failure_rhel6_x64.log
>
>
> The ISPN testsuite fails for the environment specified in the description.
> You can find the core module's tracelog for all configurations attached.
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3364:
------------------------------
Labels: 620 (was: jdg62GAblocker testsuite_stability)
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years, 5 months
[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ]
Divya Mehra updated ISPN-3633:
------------------------------
Labels: 620 (was: jdg620_dm jdg62GAblocker)
> InvalidateL1Command during ST should not cancel writing the entry by ST
> -----------------------------------------------------------------------
>
> Key: ISPN-3633
> URL: https://issues.jboss.org/browse/ISPN-3633
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry.
> Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once.
--
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
12 years, 5 months