May 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1108) Test(s) ignored by maven

by Mircea Markus (JIRA)

Test(s) ignored by maven ------------------------ Key: ISPN-1108 URL: https://issues.jboss.org/browse/ISPN-1108 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.0.0.CR2 Reporter: Mircea Markus Assignee: Manik Surtani "mvn test" doesn't run the test TransactionsSpanningReplicatedCaches. It does run though other tests from that package, ex: TransactionsSpanningDistributedCachesTest. TransactionsSpanningReplicatedCaches is marked as sequential = true (which is redundant). I've tried removing the sequential attribute, but the same thing happened: the test was not run. The test runs successfully when specified through: mvn test -Dtest=TransactionsSpanningReplicatedCaches While here, also consider removing the mandatory "testName" attribute from @Tests. TestNG now has an @Test (singleThreaded) attribute that: "If set to true, all the methods on this test class are guaranteed to run sequentially, even if the tests are currently being run with parallel="true". This attribute can only be used at the class level and will be ignored if used at the method level." -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
10
0 / 0

[JBoss JIRA] Created: (ISPN-835) State transfer should not force all invocations to be synchronous

by Galder Zamarreño (JIRA)

State transfer should not force all invocations to be synchronous ----------------------------------------------------------------- Key: ISPN-835 URL: https://issues.jboss.org/browse/ISPN-835 Project: Infinispan Issue Type: Bug Components: RPC, State transfer Affects Versions: 4.2.0.CR4, 4.1.0.Final Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final Enabling state transfer is forcing even asynchronous caches to become synchronous. A better way is needed to make sure state transfer works correctly (sync calls needed here) while normal replication calls remain asynchronous/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

5
34
0 / 0

[JBoss JIRA] Created: (ISPN-996) Create an infinispan-cdi module containing integration with CDI

by Manik Surtani (JIRA)

Create an infinispan-cdi module containing integration with CDI --------------------------------------------------------------- Key: ISPN-996 URL: https://issues.jboss.org/browse/ISPN-996 Project: Infinispan Issue Type: Feature Request Components: CDI integration Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.CR1, 5.0.0.FINAL Depends on SEAM-45 * Cache definition, configuration and injection * Caching content of producer methods on beans * Wiki/screencast to demonstrate usage -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

5
26
0 / 0

[JBoss JIRA] Created: (ISPN-359) Affinity accross caches - static or dynamic

by Tero Heinonen (JIRA)

Affinity accross caches - static or dynamic ------------------------------------------- Key: ISPN-359 URL: https://jira.jboss.org/jira/browse/ISPN-359 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.0.0.Final Reporter: Tero Heinonen Assignee: Manik Surtani Programmable affinity either through: 1) statically (e.g. annotating a certain field as the key for consistent hashing) - in our case this cannot be based on the hashCode() as the affinity requirement and object identity are not directly related 2) dynamically (e.g. providing a overridable/annotatable consistentHashCode() function) This would help to assign entities (in multiple Caches), which are needed together in the same nodes (to avoid remote lookups) -- 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

14 years, 2 months

7
23
0 / 0

[JBoss JIRA] Created: (ISPN-312) Ability to group data entries

by Mindaugas Žakšauskas (JIRA)

Ability to group data entries ----------------------------- Key: ISPN-312 URL: https://jira.jboss.org/jira/browse/ISPN-312 Project: Infinispan Issue Type: Feature Request Components: Core API, Distributed Cache, Eviction, Locking and Concurrency Affects Versions: 4.0.0.CR2 Reporter: Mindaugas Žakšauskas Assignee: Manik Surtani Priority: Minor This is a spin-off from http://lists.jboss.org/pipermail/infinispan-dev/2009-December/001968.html. The requested feature would allow distinct entries to be assigned to custom arbitrary groups. Later in time those groups could be flushed on demand without any knowledge of entry keys. This feature exists in other open source cache library, see: http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/base/Cac... -- 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

14 years, 2 months

7
15
0 / 0

[JBoss JIRA] Created: (ISPN-1000) PUSH based rehashing

by Manik Surtani (JIRA)

PUSH based rehashing -------------------- Key: ISPN-1000 URL: https://issues.jboss.org/browse/ISPN-1000 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.2.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA2, 5.0.0.FINAL Current rehash schemes are based on a PULL of state. Joiners (and new owners after a leave) pull state from their neighbours. This JIRA is to reimplement this as a PUSH based scheme, where all nodes detect new joiners (or leavers) and analyse their internal state and determine what needs to be pushed where. The scheme should be more robust, involving far fewer RPCs and coordination, and would work better for merge views detected when partitions heal. Based on Bela's prototype on https://github.com/belaban/infinispan/tree/rebalance-changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

5
11
0 / 0

[JBoss JIRA] Created: (ISPN-1096) Rework application class loading to be more friendly to modular environments

by Pete Muir (JIRA)

Rework application class loading to be more friendly to modular environments ---------------------------------------------------------------------------- Key: ISPN-1096 URL: https://issues.jboss.org/browse/ISPN-1096 Project: Infinispan Issue Type: Feature Request Reporter: Pete Muir Assignee: Manik Surtani There are two issues with modularity/classloading in Infinispan: 1) Using the TCCL as the classloader to load Infinispan classes is a bad idea. Instead we should use org.infinispan.foo.Bar.getClass().getClassLoader(). This has been addressed as a separate issue. 2) When we need to load application classes we need a different approach to that used today. Most of the time the TCCL is perfect for this. However *sometimes* Infinispan may be invoked outside of the application, when the TCCL may not be set in AS7. Jason and I discussed three options: a) require (through a platform integration documentation contract) that the TCCL must always be set when Infinispan is invoked. b) Have some sort of InvocationContext which knows what the correct classloader to use is (aka Hibernate/Seam/Weld design where there is a per-application construct based on a ThreadLocal). Given this hasn't been designed into the core, it seems like a large retrofit c) Make users specify the CL (directly or indirectly) via the API (as we discussed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
16
0 / 0

[JBoss JIRA] Created: (ISPN-83) Remove dependency on JGroups FLUSH

by Manik Surtani (JIRA)

Remove dependency on JGroups FLUSH ---------------------------------- Key: ISPN-83 URL: https://jira.jboss.org/jira/browse/ISPN-83 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA FLUSH is needed to control messages not being sent when a new view is installed, as we have observed that without this, messages get dropped by the joiner. We need to find a better way to deal with this as FLUSH is expensive and not very scalable. -- 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

14 years, 3 months

4
28
0 / 0

[JBoss JIRA] Created: (ISPN-976) TopologyAwareConsistentHash / numOwners=1

by Mircea Markus (JIRA)

TopologyAwareConsistentHash / numOwners=1 ----------------------------------------- Key: ISPN-976 URL: https://issues.jboss.org/browse/ISPN-976 Project: Infinispan Issue Type: Bug Reporter: Mircea Markus Assignee: Mircea Markus Priority: Minor Problem is fully described here: http://community.jboss.org/message/590754#590754 Setting prio to minor as there's not a lot of sense in having numOwners=1 and TACH. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1036) NPE at transaction rollback

by Sanne Grinovero (JIRA)

NPE at transaction rollback --------------------------- Key: ISPN-1036 URL: https://issues.jboss.org/browse/ISPN-1036 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.BETA1 Reporter: Sanne Grinovero Assignee: Mircea Markus Fix For: 5.0.0.BETA2 I'm not sure how it happened or how to reproduce it, but I think it might make sense to inspect the code and consider that "TransactionTable.getLocalTransaction" might return null. I think it timed out because I was having a breackpoit during debug, I found this stacktrace later in the logs: {noformat} 12:43:09,548 INFO SessionFactoryImpl:927 - closing 12:43:30,047 WARN arjuna:471 - ARJUNA-12117 TransactionReaper::check timeout for TX 0:ffff7f000001:e41d:4d9da322:6 in state RUN 12:43:30,047 WARN arjuna:387 - ARJUNA-12095 Abort of action id 0:ffff7f000001:e41d:4d9da322:6 invoked while multiple threads active within it. 12:43:30,048 WARN arjuna:435 - ARJUNA-12108 CheckedAction::check - atomic action 0:ffff7f000001:e41d:4d9da322:6 aborting with 1 threads active! 12:43:30,049 ERROR TransactionCoordinator:125 - Exception while rollback java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.infinispan.transaction.TransactionTable.getLocalTransaction(TransactionTable.java:329) at org.infinispan.interceptors.InvocationContextInterceptor.stoppingAndNotAllowed(InvocationContextInterceptor.java:130) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:80) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:62) at org.infinispan.commands.AbstractVisitor.visitRollbackCommand(AbstractVisitor.java:111) at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:47) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:76) at org.infinispan.commands.AbstractVisitor.visitRollbackCommand(AbstractVisitor.java:111) at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:47) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273) at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:123) at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:90) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:336) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2902) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2881) at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1602) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) 12:43:30,053 WARN jta:193 - ARJUNA-16045 attempted rollback of < formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffff7f000001:e41d:4d9da322:6, node_name=1, branch_uid=0:ffff7f000001:e41d:4d9da322:8, eis_name=unknown eis name > (TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=< formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffff7f000001:e41d:4d9da322:6, node_name=1, branch_uid=0:ffff7f000001:e41d:4d9da322:8, eis_name=unknown eis name >} LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=TransactionImple < ac, BasicAction: 0:ffff7f000001:e41d:4d9da322:6 status: ActionStatus.ABORTING >} org.infinispan.transaction.xa.LocalXaTransaction@329d4738}) failed with exception code XAException.XA_HEURHAZ javax.transaction.xa.XAException at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:126) at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:90) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:336) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2902) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2881) at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1602) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119) at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212) at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367) at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79) {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
10
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2011