March 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-909) Segments locked during merge

by Tristan Tarrant (JIRA)

Segments locked during merge ---------------------------- Key: ISPN-909 URL: https://issues.jboss.org/browse/ISPN-909 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.0.Final Reporter: Tristan Tarrant Assignee: Sanne Grinovero Attachments: rabbit-1-mergelock.log, rabbit-2-mergelock.log We're getting failures on acquiring locks during merges. Here is the configuration: Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction). Node 1: coordinator, IndexWriter open constantly and writing a stream of documents Node 2: opens a read-only IndexReader on-demand to perform queries (we're moving to use IndexReader.reopen() ). Occasionally when performing queries on node 2 we get the attached stack traces. We then get corrupt indexes (java.io.IOException: Read past EOF). We are using the default Distributed Segment Lock Reader, default 16K chunks and no tuning of the merge policies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

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

13 years, 8 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

13 years, 8 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-965) Query for loading some rows from CacheStore is not correct for HSQLDB 1.8.0.7

by Anatoliy Bazko (JIRA)

Query for loading some rows from CacheStore is not correct for HSQLDB 1.8.0.7 ----------------------------------------------------------------------------- Key: ISPN-965 URL: https://issues.jboss.org/browse/ISPN-965 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.2.0.Final Environment: JBoss AS 5.1.0.GA HSQLDB 1.8.0.7 Reporter: Anatoliy Bazko Assignee: Manik Surtani Loading data from CacheStore using method public final Set<InternalCacheEntry> loadSome(int maxEntries) throws CacheLoaderException failed due to query "SELECT %s, %s FROM %s LIMIT ?" is not correct for HSQLDB 1.8.0.7 since it required "ORDER BY" before "LIMIT" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-977) KeyAffinityService issue on topology change

by Mircea Markus (JIRA)

KeyAffinityService issue on topology change ------------------------------------------- Key: ISPN-977 URL: https://issues.jboss.org/browse/ISPN-977 Project: Infinispan Issue Type: Bug Affects Versions: 4.2.1.CR4 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final Complete bug description and usable UT on the forums: http://community.jboss.org/message/592275#592275 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
12
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

13 years, 8 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

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-954) Wiki on flags and use cases

by Galder Zamarreño (JIRA)

Wiki on flags and use cases --------------------------- Key: ISPN-954 URL: https://issues.jboss.org/browse/ISPN-954 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Priority: Minor Fix For: 5.0.0.BETA1 Do we have a wiki on flags and use cases? I don't think so but we need one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-749) Infinispan servers should expose some stats over JMX

by Galder Zamarreño (JIRA)

Infinispan servers should expose some stats over JMX ---------------------------------------------------- Key: ISPN-749 URL: https://jira.jboss.org/browse/ISPN-749 Project: Infinispan Issue Type: Feature Request Components: Cache Server, JMX, reporting and management Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final Infinispan servers should expose some stats of their own, such as: amount of data read, amount of data written back to clients...etc. -- 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

13 years, 8 months

2
11
0 / 0

[JBoss JIRA] Created: (ISPN-1008) Conditional replace/remove not returning previous value in Java Hot Rod client

by Galder Zamarreño (JIRA)

Conditional replace/remove not returning previous value in Java Hot Rod client ------------------------------------------------------------------------------ Key: ISPN-1008 URL: https://issues.jboss.org/browse/ISPN-1008 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.0.ALPHA3, 4.2.1.FINAL Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.0.0.CR1 The following RemoteCache APIs (and their variants) are not correctly defined: boolean replaceWithVersion(K key, V newValue, long version); boolean removeWithVersion(K key, long version); The protocol allows for the previous value to be returned if Flag.FORCE_RETURN_VALUE is used, and these APIs do not accomodate that. We should think whether it makes sense to keep the protocol as is. Does returning previous value help at all with conditional operations like these? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2011