June 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1797) Implement MongoDB based cache store

by Andrew Pushkin (JIRA)

Andrew Pushkin created ISPN-1797: ------------------------------------ Summary: Implement MongoDB based cache store Key: ISPN-1797 URL: https://issues.jboss.org/browse/ISPN-1797 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.1.0.FINAL Reporter: Andrew Pushkin Assignee: Manik Surtani I have an implementation to submit if you are interested. -- 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

7
17
0 / 0

[JBoss JIRA] Created: (ISPN-517) CacheStore impl based on LibIO, as per HornetQ's disk spooling

by Manik Surtani (JIRA)

CacheStore impl based on LibIO, as per HornetQ's disk spooling -------------------------------------------------------------- Key: ISPN-517 URL: https://jira.jboss.org/browse/ISPN-517 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final HornetQ uses Linux LibIO API to create a very fast and efficient disk spooling mechanism. Should look into the possibility of creating a CacheStore around this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
11
0 / 0

[JBoss JIRA] (ISPN-1965) Some entries not available during view change

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1965: ------------------------------------ Summary: Some entries not available during view change Key: ISPN-1965 URL: https://issues.jboss.org/browse/ISPN-1965 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.3.FINAL Reporter: Michal Linhard Assignee: Manik Surtani In the 4 node, dist mode, num-owners=2, elasticity test http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/ there is a cca 90 sec period of time where clients get null responses to GET requests on entries that should exist in the cache. first occurence: hyperion1139.log 05:31:01,202 286.409 last occurence: hyperion1135.log 05:32:45,441 390.648 total occurence count: (in all 19 driver nodes) 152241 (this doesn't mean it happens for 152K keys, because each key is retried after erroneous attempt) data doesn't seem to be lost, because these errors cease after a while and number of entries returns back to normal (see cache_entries.csv) this happens approximately in the period between node0001 is killed and cluster {node0002 - node0004} is formed (and shortly after). -- 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

3
23
0 / 0

[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, 1 month

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, 1 month

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, 1 month

4
18
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, 1 month

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, 1 month

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2012