January 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-892) Stabilise core's test suite

by Mircea Markus (JIRA)

Stabilise core's test suite --------------------------- Key: ISPN-892 URL: https://issues.jboss.org/browse/ISPN-892 Project: Infinispan Issue Type: Feature Request Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.2.1.Final, 5.0.0.Final there are many intermittent failures in the core's test suite that make it harder to use -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

5
18
0 / 0

[JBoss JIRA] Created: (ISPN-890) NPE in JGroupsTransport

by Mircea Markus (JIRA)

NPE in JGroupsTransport ----------------------- Key: ISPN-890 URL: https://issues.jboss.org/browse/ISPN-890 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.0.0.Final NPR is thrown in the following method of JGroupsTransport: private boolean needsToRejoin(View v) { if (v instanceof MergeView) { MergeView mv = (MergeView) v; org.jgroups.Address coord = v.getMembers().get(0); View winningPartition = null; for (View p : mv.getSubgroups()) { if (p.getMembers().get(0).equals(coord)) { winningPartition = p; break; } } if (!winningPartition.containsMember(channel.getAddress())) return true; //!!! here is where NPE is thrown } return false; } Here is the stack: 2011-01-24 15:14:01,842 ERROR [org.jgroups.protocols.pbcast.NAKACK] (Incoming-1,Infinispan-Cluster,NodeE-9505) couldn't deliver message [dst: <null>, src: NodeE-9505 (3 headers), size=0 bytes] java.lang.NullPointerException at org.infinispan.remoting.transport.jgroups.JGroupsTransport.needsToRejoin(JGroupsTransport.java:521) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$000(JGroupsTransport.java:88) at org.infinispan.remoting.transport.jgroups.JGroupsTransport$NotifyMerge.emitNotification(JGroupsTransport.java:465) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:502) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:728) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:771) at org.jgroups.JChannel.up(JChannel.java:1466) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:953) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:440) at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:262) at org.jgroups.protocols.FRAG2.up(FRAG2.java:189) at org.jgroups.protocols.FC.up(FC.java:502) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:596) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:243) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:796) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.up(UNICAST.java:309) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:842) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:675) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131) at org.jgroups.protocols.FD.up(FD.java:265) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:268) at org.jgroups.protocols.MERGE2.up(MERGE2.java:209) at org.jgroups.protocols.Discovery.up(Discovery.java:291) at org.jgroups.protocols.TP.passMessageUp(TP.java:1092) at org.jgroups.protocols.TP$3.run(TP.java:1016) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Seems like winningPartition might be null in the method. This fails in 1/50 runs of StateTransferFunctionalTest. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-901) When activating an entry, don't remove from cachestore if cachestore is shared

by Manik Surtani (JIRA)

When activating an entry, don't remove from cachestore if cachestore is shared ------------------------------------------------------------------------------ Key: ISPN-901 URL: https://issues.jboss.org/browse/ISPN-901 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Priority: Critical Fix For: 4.2.1.Final ... since other nodes may be relying on the entry being present in the shared store. This pattern fails, for example: {code} NodeA.put(k, v) // replicates to NodeB as well NodeA.evict(k) // k gets persisted NodeB.evict(k) // k gets persisted NodeA.get(k) // k gets activated and removed from the store NodeB.get(k) // fails! NodeB won't ever see k again! {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-903) CacheStore throws a NPE when preparing a transaction which includes a key it doesn't own

by Manik Surtani (JIRA)

CacheStore throws a NPE when preparing a transaction which includes a key it doesn't own ---------------------------------------------------------------------------------------- Key: ISPN-903 URL: https://issues.jboss.org/browse/ISPN-903 Project: Infinispan Issue Type: Bug Components: Distributed Cache, Loaders and Stores, Transactions Affects Versions: 4.2.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Priority: Critical Fix For: 4.2.1.Final When a transaction is prepared, the {{PrepareCommand}} is broadcast to all participants in the transaction. However, recipients only replay Commands whose keys map to their node (by consulting the {{DistributionManager}}). When the {{PrepareCommand}} reaches the {{CacheStoreInterceptor}}, however, the {{CacheStoreInterceptor}} is unable to handle all of the modifications in the prepare as it doesn't filter out modifications based on what is mapped to the node in question. This results in a {{NullPointerExceptoion}} on the receiving node, which causes the transaction to abort: {code} java.lang.NullPointerException at org.infinispan.interceptors.CacheStoreInterceptor.getStoredEntry(CacheStoreInterceptor.java:337) at org.infinispan.interceptors.CacheStoreInterceptor$StoreModificationsBuilder.visitPutKeyValueCommand(CacheStoreInterceptor.java:288) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:72) at org.infinispan.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:255) at org.infinispan.interceptors.CacheStoreInterceptor.visitPrepareCommand(CacheStoreInterceptor.java:175) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:116) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:106) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:116) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:48) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:116) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:103) at org.infinispan.interceptors.DistTxInterceptor.visitPrepareCommand(DistTxInterceptor.java:59) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:116) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:87) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:58) at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:106) at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:116) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273) at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:107) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:94) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:179) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:153) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:577) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:488) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:364) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:770) at org.jgroups.JChannel.up(JChannel.java:1467) {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (ISPN-293) implement asynchronous get method getAsync()

by Sanne Grinovero (JIRA)

implement asynchronous get method getAsync() -------------------------------------------- Key: ISPN-293 URL: https://jira.jboss.org/jira/browse/ISPN-293 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 4.0.0.CR3 Like other async methods existing it would be useful (natural) to have a method getAsync() for prefetching of data not immediately required. -- 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

13 years, 10 months

4
15
0 / 0

[JBoss JIRA] Created: (ISPN-856) Fix compatibility issues of Query module with Lucene 3 and Hibernate Search 3.3.0

by Sanne Grinovero (JIRA)

Fix compatibility issues of Query module with Lucene 3 and Hibernate Search 3.3.0 --------------------------------------------------------------------------------- Key: ISPN-856 URL: https://issues.jboss.org/browse/ISPN-856 Project: Infinispan Issue Type: Task Components: Querying Affects Versions: 5.0.0.ALPHA1 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.0.0.BETA1 Updating the dependency to Hibernate Search 3.3.0.Final or 3.4.0-SNAPSHOT is currently not possible, many changes are needed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-906) AtomicMap.deleteAtomicMap(cache, key)

by Patrick McFarland (JIRA)

AtomicMap.deleteAtomicMap(cache, key) ------------------------------------- Key: ISPN-906 URL: https://issues.jboss.org/browse/ISPN-906 Project: Infinispan Issue Type: Feature Request Reporter: Patrick McFarland Assignee: Manik Surtani There seems to be no way to delete an atomic map once created. There probably should be an interceptor for this. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-271) Expose global information in RpcManagerImpl via CacheManager

by Galder Zamarreno (JIRA)

Expose global information in RpcManagerImpl via CacheManager ------------------------------------------------------------ Key: ISPN-271 URL: https://jira.jboss.org/jira/browse/ISPN-271 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management, RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 RpcManagerImpl exposes information that are both global to all caches under a cache manager and information that is specific to a cache. An idea would be to expose any global information via CacheManager mbean instead, i.e. address, cluster members And the rest, stuff that is cache specific, expose via rpc manager mbean, -- 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

13 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-849) testTransactional doesn't ever work

by luca stancapiano (JIRA)

testTransactional doesn't ever work ----------------------------------- Key: ISPN-849 URL: https://issues.jboss.org/browse/ISPN-849 Project: Infinispan Issue Type: Bug Environment: mac osx Reporter: luca stancapiano Assignee: Manik Surtani I'm triing testTransactional inside distribution.rehash.ConcurrentNonOverlappingLeaveTest . Often it doesn't update the c1 cache with the value "transactionally_replaced" instead of "v1". I thought about a syncronization problem of the Threads but I see that the put of the field always is executed before the get. Actually the problem seems be in org.infinispan.distribution.rehash.RehashTestBase class (95-109): TransactionManager t1 = TestingUtil.getTransactionManager(c1); t1.begin(); c1.put(keys.get(0), "transactionally_replaced"); Transaction tx = t1.getTransaction(); tx.enlistResource(new XAResourceAdapter() { public int prepare(Xid id) { // this would be called *after* the cache prepares. try { l.await(); } catch (InterruptedException e) { } return XAResource.XA_OK; } }); t1.commit(); maybe sometime there is a rollback -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-904) Cache.delete();

by Patrick McFarland (JIRA)

Cache.delete(); --------------- Key: ISPN-904 URL: https://issues.jboss.org/browse/ISPN-904 Project: Infinispan Issue Type: Feature Request Reporter: Patrick McFarland Assignee: Manik Surtani There seems to be no ability to completely remove a populated cache from Infinispan -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2011