August 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2062) CrashedMemberDetectorListener should check whether invocations are allowed

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2062: -------------------------------------- Summary: CrashedMemberDetectorListener should check whether invocations are allowed Key: ISPN-2062 URL: https://issues.jboss.org/browse/ISPN-2062 Project: Infinispan Issue Type: Enhancement Components: Cache Server Affects Versions: 5.1.5.CR1, 5.1.4.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.5.FINAL Instead of just checking whether the cache is terminated, since this check misses other situations such as stopping. -- 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, 3 months

3
8
0 / 0

[JBoss JIRA] (ISPN-2081) Transaction leak caused by reordering between prepare and commit

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2081: ----------------------------------- Summary: Transaction leak caused by reordering between prepare and commit Key: ISPN-2081 URL: https://issues.jboss.org/browse/ISPN-2081 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.1.5.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Attachments: RollbackNotSentBeforePrepareTest.java There's no ordering between the prepare and commit/rollback messages, as the later are sent OOB. With this in mind, the following transaction leak might happen: Tx1 send prepare on nodes {A,B} 1. the message reaches A and timeouts but hasn't yet been processed on B 2. The transaction originator reacts immediately to the timeout received from A without waiting the response from B and sends a rollback request 3. The rollback request is processed on A and B 4. The initial prepare is then processed on B At this point we have an orphan transaction prepare on B. Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is a memory leak. The solution would be to wait at 2 for all the prepare messages *before* sending the rollback. Attached is a unit test to reproduce the issue. Related mailing list thread: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in... -- 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, 3 months

5
25
0 / 0

[JBoss JIRA] (ISPN-1954) Wrong ServerWorker thread name in Hot rod server

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1954: ------------------------------------ Summary: Wrong ServerWorker thread name in Hot rod server Key: ISPN-1954 URL: https://issues.jboss.org/browse/ISPN-1954 Project: Infinispan Issue Type: Bug Components: Cache Server Reporter: Michal Linhard Assignee: Galder Zamarreño Priority: Minor When debugging/profiling EDG, we're seeing HotRod server calls being executed by MemcachedServerWorker threads. -- 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, 3 months

4
18
0 / 0

[JBoss JIRA] (ISPN-2187) Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2187: ----------------------------------- Summary: Pre-Invocation flag PUT_FOR_EXTERNAL_READ throws exception Key: ISPN-2187 URL: https://issues.jboss.org/browse/ISPN-2187 Project: Infinispan Issue Type: Bug Components: Core API Reporter: Anna Manukyan Assignee: Manik Surtani Hi, While writing tests for Infinispan Flag.PUT_FOR_EXTERNAL_READ the following issue has been found. In documentation it is said: PUT_FOR_EXTERNAL_READ Flags the invocation as a Cache.putForExternalRead(Object, Object) call, as opposed to a regular Map.put(Object, Object). And the documentation for Cache.putForExternalRead(Object, Object) says: void putForExternalRead(K key, V value) ................... Errors and exceptions are 'silent' - logged at a much lower level than normal, and this method does not throw exceptions The issue is the following: when trying to perform operation using PUT_FOR_EXTERNAL_READ flag, the exception is thrown, it is not 'silent'. cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value); The test is the following: public void testExceptionSuppression() throws Exception { Cache cache1 = cache(0, "replSync"); Cache cache2 = cache(1, "replSync"); Transport mockTransport = mock(Transport.class); RpcManagerImpl rpcManager = (RpcManagerImpl) TestingUtil.extractComponent(cache1, RpcManager.class); Transport originalTransport = TestingUtil.extractComponent(cache1, Transport.class); try { Address mockAddress1 = mock(Address.class); Address mockAddress2 = mock(Address.class); List<Address> memberList = new ArrayList<Address>(2); memberList.add(mockAddress1); memberList.add(mockAddress2); rpcManager.setTransport(mockTransport); when(mockTransport.getMembers()).thenReturn(memberList); when(mockTransport.getViewId()).thenReturn(originalTransport.getViewId()); when(mockTransport.invokeRemotely(anyAddresses(), (CacheRpcCommand) anyObject(), anyResponseMode(), anyLong(), anyBoolean(), (ResponseFilter) anyObject())) .thenThrow(new RuntimeException("Barf!")); try { cache1.put(key, value); fail("Should have barfed"); } catch (RuntimeException re) { } // clean up any indeterminate state left over try { cache1.remove(key); fail("Should have barfed"); } catch (RuntimeException re) { } assertNull("Should have cleaned up", cache1.get(key)); // should not barf cache1.putForExternalRead(key, value); /** ------------------- Testing the same feature with Flag.PUT_FOR_EXTERNAL_READ **/ try { cache1.remove(key); fail("Should have barfed"); } catch (RuntimeException re) { } cache1.getAdvancedCache().withFlags(Flag.PUT_FOR_EXTERNAL_READ).put(key, value); } finally { if (rpcManager != null) rpcManager.setTransport(originalTransport); } } Best regards, Anna. -- 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, 3 months

5
15
0 / 0

[JBoss JIRA] (ISPN-2137) Potential tx lock leaks when nodes are added to the cluster

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2137: ----------------------------------- Summary: Potential tx lock leaks when nodes are added to the cluster Key: ISPN-2137 URL: https://issues.jboss.org/browse/ISPN-2137 Project: Infinispan Issue Type: Bug Components: State transfer, Transactions Affects Versions: 5.1.5.FINAL Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.x, 5.2.0.ALPHA2, 5.2.0.FINAL -- 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, 3 months

5
17
0 / 0

[JBoss JIRA] Created: (ISPN-143) Security needs to be considered

by Manik Surtani (JIRA)

Security needs to be considered ------------------------------- Key: ISPN-143 URL: https://jira.jboss.org/jira/browse/ISPN-143 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.GA We need to consider security for Infinispan. Storing state on the cloud only makes sense if the data can be secured. Both encryption and authentication need to be considered, and all levels (wire protocol, cache store, public API, server module, etc) need to be taken in to consideration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
6
0 / 0

[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, 4 months

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, 4 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, 4 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, 4 months

2
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2012