July 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2138) Could not execute MapReduce on AS7.1.1 getting java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue

by Sandro Sonntag (JIRA)

Sandro Sonntag created ISPN-2138: ------------------------------------ Summary: Could not execute MapReduce on AS7.1.1 getting java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue Key: ISPN-2138 URL: https://issues.jboss.org/browse/ISPN-2138 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.5.FINAL Reporter: Sandro Sonntag Assignee: Manik Surtani Priority: Blocker If I execute a MapReduce Task in AS7 a ClassCastEx occurs in the Mapper. Thanks for help. ~Sandro java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to de.adorsys.fireonec2.server.PrimeStats de.adorsys.fireonec2.server.PrimeCountMapper.map(PrimeCountMapper.java:10) org.infinispan.commands.read.MapReduceCommand.perform(MapReduceCommand.java:144) org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:285) org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:358) de.adorsys.fireonec2.server.StatsService.map(StatsService.java:44) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
28
0 / 0

[JBoss JIRA] (ISPN-1996) Failed to prepare view exceptions

by dex chen (JIRA)

dex chen created ISPN-1996: ------------------------------ Summary: Failed to prepare view exceptions Key: ISPN-1996 URL: https://issues.jboss.org/browse/ISPN-1996 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.3.FINAL Environment: ISPN 5.1.3.Final; Java 7; Cent OS 3-node cluster in replication mode using jgroups-tcp config. Reporter: dex chen Assignee: Manik Surtani I saw lot (re-curring) cache view exceptions (below) when I start up a 3 node cluster. I am running ISPN 5.1.3 final with replication mode, and jgroup-tcp config. In this case, I start first 2 nodes first, and later try to join the 3rd node. ======================================= 2012-04-10/12:13:45.714/MDT [CacheViewInstaller-3,portal1.net-1609] ERROR org.infinispan.cacheviews.CacheViewsManagerImpl[263] - ISPN000172: Failed to prepare view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} for cache ispn-cipherkey, rolling back to view CacheView{viewId=831, members=[portal1.net-1609]} java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:262) at java.util.concurrent.FutureTask.get(FutureTask.java:119) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) 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: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:172) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:488) at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) ... 5 more Caused by: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:107) at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481) at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:125) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) at org.jgroups.JChannel.up(JChannel.java:716) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:882) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759) at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:595) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) at org.jgroups.protocols.FD.up(FD.java:273) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:282) at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) at org.jgroups.protocols.Discovery.up(Discovery.java:359) at org.jgroups.protocols.TP.passMessageUp(TP.java:1174) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1722) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1704) ... 3 more 2012-04-10/12:13:46.715/MDT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
8
0 / 0

[JBoss JIRA] (ISPN-2172) Cache removals not removing L1 cached values in non-owners

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2172: -------------------------------------- Summary: Cache removals not removing L1 cached values in non-owners Key: ISPN-2172 URL: https://issues.jboss.org/browse/ISPN-2172 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.2.0.ALPHA2, 5.1.5.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Critical Fix For: 5.2.0.ALPHA3, 5.2.0.FINAL There appears to be an issue L1 and removals. Seems like on removal, non-owners are not invalidated and data is left in memory. If using a Hot Rod server, it would appear as if the remote get operations don't return anything after removal is cos it goes to an owner node, where data is indeed removed. However, if you try to build a test case with embedded cache, it clearly shows that after removal, data is left in memory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
18
0 / 0

[JBoss JIRA] (ISPN-1731) Threads waiting for key locks should not block state transfer

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1731: ---------------------------------- Summary: Threads waiting for key locks should not block state transfer Key: ISPN-1731 URL: https://issues.jboss.org/browse/ISPN-1731 Project: Infinispan Issue Type: Task Components: State transfer Affects Versions: 5.1.0.CR3, 5.0.1.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL A write/lock command holds the state transfer lock for its entire duration, including while waiting to acquire key locks. Because of this, we can get a deadlock scenario: 1. Tx1 waits for key k1 while holding the state transfer lock 2. State transfer waits for Tx1 while blocking new write commands 3. Tx2 waits for state transfer to end while holding the k1 lock The only way out of this scenario at the moment is for Tx1 to time out and fail to acquire the lock. We should make it possible to release the state transfer lock temporarily and return to waiting for the key lock after state transfer has ended. ISPN-1424 might make this issue obsolete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1271) Consistent Hash externalizer loses grouping configuration

by Dan Berindei (JIRA)

Consistent Hash externalizer loses grouping configuration --------------------------------------------------------- Key: ISPN-1271 URL: https://issues.jboss.org/browse/ISPN-1271 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.0.0.CR8 Reporter: Dan Berindei Assignee: Pete Muir -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

6
13
0 / 0

[JBoss JIRA] (ISPN-1704) IllegalStateException in surviving nodes during node crash in cluster

by Michal Linhard (Created) (JIRA)

IllegalStateException in surviving nodes during node crash in cluster --------------------------------------------------------------------- Key: ISPN-1704 URL: https://issues.jboss.org/browse/ISPN-1704 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.CR3 Reporter: Michal Linhard Assignee: Manik Surtani This bug appeared in EDG build 96: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-build-... that contains Infinispan 5.1.0.CR3 Test scenario: 1. start 4 nodes (distributed cache) 2. wait 2 min 3. kill node2 4. wait 2 min 5. start node2 6. wait 2 min and end the test server side logs: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experi... client side logs: http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experi... http://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-QE/job/edg-60-experi... after crashing of the node2, there were no other succesfull requests, most of the requests ended with this error: {code} ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-1-43) ISPN000136: Execution error: java.lang.IllegalStateException: Trying to release state transfer shared lock without acquiring it first {code} before showing the error on the client side, the requests had been blocked around 1,5min -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

7
26
0 / 0

[JBoss JIRA] Created: (ISPN-1263) Allow a type safe selection of the cache used by the JCache interceptors

by Kevin Pollet (JIRA)

Allow a type safe selection of the cache used by the JCache interceptors ------------------------------------------------------------------------ Key: ISPN-1263 URL: https://issues.jboss.org/browse/ISPN-1263 Project: Infinispan Issue Type: Feature Request Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Priority: Minor Currently the name of the cache which will be used by the JCache interceptors has to be specified in JCache annotations (e.g {{@CacheResult(cacheName="greeting-cache"}}). This can be error prone (typo, refactoring ...). The CDI integration module provides the possibility to associate a qualifier to a cache. This qualifier could be re-used to provide a type safe selection of the cache used by a JCache interceptor. Something like: {code} public class GreetingService { @CacheResult @GreetingCache public String greet(String name) { return "Hello" + name; } } {code} Here we need to be in sync with JCache specification. In my understanding of the spec the cache name is required for {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} (but currently in the API there is a default value). For {{@CacheResult}} if no cache name is defined a default one is used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1266) Add more integration tests with Arquillian

by Kevin Pollet (JIRA)

Add more integration tests with Arquillian ------------------------------------------ Key: ISPN-1266 URL: https://issues.jboss.org/browse/ISPN-1266 Project: Infinispan Issue Type: Task Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.FINAL This extension should be tested with: * Open Web Beans * JBoss AS7 * GlassFish -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
13
0 / 0

[JBoss JIRA] Created: (ISPN-1253) Integrate the Tattletale Maven plugin into Infinispan.

by Navin Surtani (JIRA)

Integrate the Tattletale Maven plugin into Infinispan. ------------------------------------------------------ Key: ISPN-1253 URL: https://issues.jboss.org/browse/ISPN-1253 Project: Infinispan Issue Type: Task Components: Build process Reporter: Navin Surtani Assignee: Navin Surtani Priority: Minor Fix For: 5.0.0.FINAL Make use of the tattletale maven plugin for infinispan. This way there will not be issues similar to ISPN-1234 cropping up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

6
7
0 / 0

[JBoss JIRA] (ISPN-1491) Provide methods to retrieve the CacheKey parameters

by Kevin Pollet (Created) (JIRA)

Provide methods to retrieve the CacheKey parameters --------------------------------------------------- Key: ISPN-1491 URL: https://issues.jboss.org/browse/ISPN-1491 Project: Infinispan Issue Type: Enhancement Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Fix For: 5.1.0.BETA4, 5.1.0.FINAL Currently, it's not possible to retrieve the parameter values composing the {{CacheKey}} (generated by JCache interceptors). For that, we could introduce two interfaces. * {{SimpleCacheKey<T>}} used when only one parameter is used as key. This interface could add the following method {{T getValue()}} * {{ComposedCacheKey}} used when the key is composed by more than one parameter. This interface could add the following method {{Object[] getValues()}} Here, we need to ensure that we are compliant with the specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2012