January 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-121) Create a cache store to work with GAE/J's JPA implementation

by Manik Surtani (JIRA)

Create a cache store to work with GAE/J's JPA implementation ------------------------------------------------------------ Key: ISPN-121 URL: https://jira.jboss.org/jira/browse/ISPN-121 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA A cache store that could store state on Google AppEngine for Java's JPA backend. -- 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, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-720) Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural)

by Trustin Lee (JIRA)

Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural) ------------------------------------------------------------------------------ Key: ISPN-720 URL: https://jira.jboss.org/browse/ISPN-720 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 CacheEntryEvictedEvent should be replaced with CacheEntriesEvictedEvent to fully utilize the improvements in EvictionListener (see ISPN-718). -- 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, 10 months

4
18
0 / 0

[JBoss JIRA] Created: (ISPN-905) CacheManager.cacheExists(String cache), CacheManager.getCacheIfExists(String cache), and Cache.exists()

by Patrick McFarland (JIRA)

CacheManager.cacheExists(String cache), CacheManager.getCacheIfExists(String cache), and Cache.exists() ------------------------------------------------------------------------------------------------------- Key: ISPN-905 URL: https://issues.jboss.org/browse/ISPN-905 Project: Infinispan Issue Type: Feature Request Reporter: Patrick McFarland Assignee: Manik Surtani There seems to be no ability to check if a populated cache exists through both CacheManager and through Cache (=is this still a valid handle) and to get a cache if it exists. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
23
0 / 0

[JBoss JIRA] Created: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0

by Paul Nardone (JIRA)

Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0 -------------------------------------------------------------------------------- Key: ISPN-663 URL: https://jira.jboss.org/browse/ISPN-663 Project: Infinispan Issue Type: Bug Components: Eviction, Loaders and Stores Affects Versions: 4.1.0.Final Environment: Win32 JRE 1.6.0_21 Reporter: Paul Nardone Assignee: Manik Surtani Attachments: InfinispanPassivationTest.java Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL. The degredation in performance is so signficant to make it impossible to use The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity. The attached test inserts 1000 values into two caches Both caches use a JdbmCacheStore and LRU PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10 PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000 4.1.0.FINAL PASSIVATIONLRU10 Time Taken : 51704 PASSIVATIONLRU1000 Time Taken : 4484 4.0.0.FINAL PASSIVATIONLRU10 Time Taken : 281 PASSIVATIONLRU1000 Time Taken : 141 4.2.0.ALPHA2 PASSIVATIONLRU10 Time Taken : 51047 PASSIVATIONLRU1000 Time Taken : 5156 -- 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, 10 months

5
36
0 / 0

[JBoss JIRA] Created: (ISPN-869) Enable automatic keyspace creation with cassandra 0.7

by Tristan Tarrant (JIRA)

Enable automatic keyspace creation with cassandra 0.7 ------------------------------------------------------ Key: ISPN-869 URL: https://issues.jboss.org/browse/ISPN-869 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 5.0.0.Final Cassandra 0.7 allows creation of keyspaces and columnfamilies at runtime. We should add a boolean flag (false by default) to automatically create the Infinispan keyspaces and columnfamilies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-721) Change CacheStore.store() to return the previous value instead of void.

by Trustin Lee (JIRA)

Change CacheStore.store() to return the previous value instead of void. ----------------------------------------------------------------------- Key: ISPN-721 URL: https://jira.jboss.org/browse/ISPN-721 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 Cache.put(key, value) operation returns a previous value. However, CacheStore.store() does not return a previous value but void. To overcome the impedance mismatch, the current implementation calls CacheStore.load() to simply get the previous value. CacheStore.store() could be improved to reduce this unnecessary round trip. -- 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, 10 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-878) update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches

by Mircea Markus (JIRA)

update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches ------------------------------------------------------------------------------- Key: ISPN-878 URL: https://issues.jboss.org/browse/ISPN-878 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.0.0.Final Update http://community.jboss.org/wiki/MultipleTiersofCaches as follows: Feedback from Galder: though, the text in the diagram is very very small and can hardly be read. Maybe you can improve it a little? Feedback from Manik: Also some more feedback: * Spelling: "Multi-Tiered", not "Multiered" * Your diagram probably wants to demonstrate 2 separate tiers, not just 1 client with a clustered server backend. E.g., FE1 --- FE2 --- FE3 =============== BE1 --- BE2 --- BE3 where FE = front-end servers (embedded, maybe an app server running a webapp, with an embedded Infinispan instance as a "near cache") BE = backend, dedicated cache tier, running Hot Rod endpoints FE configured with RemoteCacheStore, and also using Invalidation so that FE's can invalidate each other BE's running DIST for max addressable space + ultimate scalability This way, with the FE's running in INVAL mode, it doesn't matter if the BE's cannot communicate changes back to the FE's, since the FE's wil already know about changes and will invalidate accordingly. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-877) analyse, document and suggest indexing the JDBC cache store

by Mircea Markus (JIRA)

analyse, document and suggest indexing the JDBC cache store ----------------------------------------------------------- Key: ISPN-877 URL: https://issues.jboss.org/browse/ISPN-877 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.ALPHA2 Adding indexes to the JDBC cache store's backend table can drastically increase performance especially for the JdbcStringBasedCacheStore and partially for the JdbcMixedCacheStore. Investigate weather indexes can be defined through Jdbc in a portable manner (same way the tables are created on startup) or at least update documentation to describe how indexes should be defined and the advantages of having them defined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-360) create NodeJoined event

by Mircea Markus (JIRA)

create NodeJoined event ----------------------- Key: ISPN-360 URL: https://jira.jboss.org/jira/browse/ISPN-360 Project: Infinispan Issue Type: Feature Request Components: Listeners, State transfer Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529547#529547 It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc. A possible solution would be to have an NodeJoined event, that would be called whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started. For a possible workaround to this feature see the forum post. -- 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, 11 months

4
12
0 / 0

[JBoss JIRA] Created: (ISPN-887) XAResource implementation improvements (TransactionalXAResource)

by Mircea Markus (JIRA)

XAResource implementation improvements (TransactionalXAResource) ---------------------------------------------------------------- Key: ISPN-887 URL: https://issues.jboss.org/browse/ISPN-887 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.0.0.Final Reviewing the code with Jonathan Halliday has brought the following aspects (see TODOs below): package org.infinispan.transaction.xa; import org.infinispan.commands.CommandsFactory; import org.infinispan.commands.tx.CommitCommand; import org.infinispan.commands.tx.PrepareCommand; import org.infinispan.commands.tx.RollbackCommand; import org.infinispan.config.Configuration; import org.infinispan.context.InvocationContextContainer; import org.infinispan.context.impl.LocalTxInvocationContext; import org.infinispan.interceptors.InterceptorChain; import org.infinispan.util.logging.Log; import org.infinispan.util.logging.LogFactory; import javax.transaction.xa.XAException; import javax.transaction.xa.XAResource; import javax.transaction.xa.Xid; /** * This acts both as an local {@link org.infinispan.transaction.xa.CacheTransaction} and implementor of an {@link * javax.transaction.xa.XAResource} that will be called by tx manager on various tx stages. * * @author Mircea.Markus(a)jboss.com * @since 4.0 */ public class TransactionXaAdapter implements XAResource { private static final Log log = LogFactory.getLog(TransactionXaAdapter.class); private static boolean trace = log.isTraceEnabled(); //todo - comment why timeout is not used // - it is useful only if TM and client are in separate processes and TM might fail. this is because a client might tm.begin and then the TM (running separate process) crashes // - in this scenario the TM won't ever call XAResource.rollback, so these resources would be held there forever // - not affecting us as in all scenarios TM&XAResource are collocated private int txTimeout; private final InvocationContextContainer icc; private final InterceptorChain invoker; private final CommandsFactory commandsFactory; private final Configuration configuration; private final TransactionTable txTable; /** * XAResource is associated with a transaction between enlistment (XAResource.start()) XAResource.end(). It's only the * boundary methods (prepare, commit, rollback) that need to be "stateless". * Reefer to section 3.4.4 from JTA spec v.1.1 */ private final LocalTransaction localTransaction; public TransactionXaAdapter(LocalTransaction localTransaction, TransactionTable txTable, CommandsFactory commandsFactory, Configuration configuration, InterceptorChain invoker, InvocationContextContainer icc) { this.localTransaction = localTransaction; this.txTable = txTable; this.commandsFactory = commandsFactory; this.configuration = configuration; this.invoker = invoker; this.icc = icc; } /** * This can be call for any transaction object. See Section 3.4.6 (Resource Sharing) from JTA spec v1.1. */ public int prepare(Xid xid) throws XAException { //todo if I throw an exception here then I should also cleanup resources as .rollback might never be called!! LocalTransaction localTransaction = getLocalTransactionAndValidate(xid); //todo - same as last comment validateNotMarkedForRollback(localTransaction); if (configuration.isOnePhaseCommit()) { if (trace) log.trace("Received prepare for tx: {0}. Skipping call as 1PC will be used.", xid); return XA_OK; } PrepareCommand prepareCommand = commandsFactory.buildPrepareCommand(localTransaction.getGlobalTransaction(), localTransaction.getModifications(), configuration.isOnePhaseCommit()); if (trace) log.trace("Sending prepare command through the chain: " + prepareCommand); LocalTxInvocationContext ctx = icc.createTxInvocationContext(); ctx.setLocalTransaction(localTransaction); try { invoker.invoke(ctx, prepareCommand); if (localTransaction.isReadOnly()) { if (trace) log.trace("Readonly transaction: " + localTransaction.getGlobalTransaction()); // force a cleanup to release any objects held. Some TMs don't call commit if it is a READ ONLY tx. See ISPN-845 commit(xid, false); return XA_RDONLY; } else { return XA_OK; } } catch (Throwable e) { // todo if I throw this exception make sure that all locks are 100% cleaned up, as TM won't do any rollback call on it. // todo - handle this! -> if only a node fails to ack tx prepare, and that node is still part of the cluster, it needs to be sync with tx state. // one way of doing this is by pushing the tx state to that node until one of two happens: a) node ack or b) node is shunned from the cluster log.error("Error while processing PrepareCommand", e); throw new XAException(XAException.XAER_RMERR); } } /** * Same comment as for {@link #prepare(javax.transaction.xa.Xid)} applies for commit. */ public void commit(Xid xid, boolean isOnePhase) throws XAException { LocalTransaction localTransaction = getLocalTransactionAndValidate(xid); if (trace) log.trace("committing transaction {0}", localTransaction.getGlobalTransaction()); try { LocalTxInvocationContext ctx = icc.createTxInvocationContext(); ctx.setLocalTransaction(localTransaction); // todo this needs to be split in two: // - configuration.isOnePhaseCommit() this is not "as important", as the user ack that it doesn't "really" need consistency // - on the other case ("isOnePhase"==true) make sure that this method either commits successfully or it fails and cleans up logs eventually if (configuration.isOnePhaseCommit() || isOnePhase) { validateNotMarkedForRollback(localTransaction); if (trace) log.trace("Doing an 1PC prepare call on the interceptor chain"); PrepareCommand command = commandsFactory.buildPrepareCommand(localTransaction.getGlobalTransaction(), localTransaction.getModifications(), true); try { invoker.invoke(ctx, command); } catch (Throwable e) { log.error("Error while processing 1PC PrepareCommand", e); throw new XAException(XAException.XAER_RMERR); } } else { CommitCommand commitCommand = commandsFactory.buildCommitCommand(localTransaction.getGlobalTransaction()); try { invoker.invoke(ctx, commitCommand); } catch (Throwable e) { log.error("Error while processing 1PC PrepareCommand", e); throw new XAException(XAException.XAER_RMERR); } } } finally { cleanup(localTransaction); } } /** * Same comment as for {@link #prepare(javax.transaction.xa.Xid)} applies for commit. */ public void rollback(Xid xid) throws XAException { rollbackImpl(xid, commandsFactory, icc, invoker, txTable); } public static void rollbackImpl(Xid xid, CommandsFactory commandsFactory, InvocationContextContainer icc, InterceptorChain invoker, TransactionTable txTable) throws XAException { LocalTransaction localTransaction = txTable.getLocalTransaction(xid); if (localTransaction == null) { if (trace) log.trace("no tx found for {0}", xid); throw new XAException(XAException.XAER_NOTA); } if (trace) log.trace("rollback transaction {0} ", localTransaction.getGlobalTransaction()); RollbackCommand rollbackCommand = commandsFactory.buildRollbackCommand(localTransaction.getGlobalTransaction()); LocalTxInvocationContext ctx = icc.createTxInvocationContext(); ctx.setLocalTransaction(localTransaction); try { invoker.invoke(ctx, rollbackCommand); } catch (Throwable e) { log.error("Exception while rollback", e); throw new XAException(XAException.XA_HEURHAZ); } finally { cleanupImpl(localTransaction, txTable, icc); } } private LocalTransaction getLocalTransactionAndValidate(Xid xid) throws XAException { LocalTransaction localTransaction1 = txTable.getLocalTransaction(xid); if (localTransaction1 == null) { log.error("This should not happen when XAResource and TM are in the same process! No tx found for {0}", xid); throw new XAException(XAException.XAER_NOTA); } return localTransaction1; } public void start(Xid xid, int i) throws XAException { localTransaction.setXid(xid); txTable.addLocalTransactionMapping(localTransaction); if (trace) log.trace("start called on tx " + this.localTransaction.getGlobalTransaction()); } public void end(Xid xid, int i) throws XAException { if (trace) log.trace("end called on tx " + this.localTransaction.getGlobalTransaction()); } public void forget(Xid xid) throws XAException { if (trace) log.trace("forget called"); } public int getTransactionTimeout() throws XAException { if (trace) log.trace("start called"); return txTimeout; } public boolean isSameRM(XAResource xaResource) throws XAException { if (!(xaResource instanceof TransactionXaAdapter)) { return false; } TransactionXaAdapter other = (TransactionXaAdapter) xaResource; return other.equals(this); } public Xid[] recover(int i) throws XAException { if (trace) log.trace("recover called: " + i); return null; } public boolean setTransactionTimeout(int i) throws XAException { this.txTimeout = i; return true; } @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof TransactionXaAdapter)) return false; TransactionXaAdapter that = (TransactionXaAdapter) o; return this.localTransaction.equals(that.localTransaction); } @Override public int hashCode() { return localTransaction.getGlobalTransaction().hashCode(); } @Override public String toString() { return "TransactionXaAdapter{" + "localTransaction=" + localTransaction + '}'; } private void validateNotMarkedForRollback(LocalTransaction localTransaction) throws XAException { if (localTransaction.isMarkedForRollback()) { if (trace) log.trace("Transaction already marked for rollback: {0}", localTransaction); throw new XAException(XAException.XA_RBROLLBACK); } } private void cleanup(LocalTransaction localTransaction) { TransactionXaAdapter.cleanupImpl(localTransaction, txTable, icc); } private static void cleanupImpl(LocalTransaction localTransaction, TransactionTable txTable, InvocationContextContainer icc) { txTable.removeLocalTransaction(localTransaction); icc.suspend(); } } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 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