March 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1001) Should handle 3-way (or more) merges

by Manik Surtani (JIRA)

Should handle 3-way (or more) merges ------------------------------------ Key: ISPN-1001 URL: https://issues.jboss.org/browse/ISPN-1001 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 The current fix for handling merge views (ISPN-923) only handles to 2-way merges reliably. A split of a network into even more partitions could result in data loss. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
17
0 / 0

[JBoss JIRA] Created: (ISPN-328) Async store to support frequency based flushing

by Galder Zamarreno (JIRA)

Async store to support frequency based flushing ----------------------------------------------- Key: ISPN-328 URL: https://jira.jboss.org/jira/browse/ISPN-328 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement frequency based flushing in the async store. This is also called, Scheduled Write-Behing Strategy. -- 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, 2 months

5
11
0 / 0

[JBoss JIRA] Created: (ISPN-604) Re-design CacheStore transactions

by Mircea Markus (JIRA)

Re-design CacheStore transactions ---------------------------------- Key: ISPN-604 URL: https://jira.jboss.org/browse/ISPN-604 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2, 4.0.0.Final Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.0.0.Final Current(4.1.x) transaction implementation in CacheStores is brocken in several ways: 1st problem. - AbstractCacheStore.prepare: public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it). 2nd problem. This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue. When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction. Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection. Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1] This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource). Suggested fix: - the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now) - this requires API changes in CacheStore, e.g. void store(InternalCacheEntry entry) should become void store(InternalCacheEntry entry, GlobalTransaction gtx) (gtx would be null if this is not a transactional call). [1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction -- 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, 2 months

4
9
0 / 0

[JBoss JIRA] Created: (ISPN-503) collate keys in replication queue

by Mircea Markus (JIRA)

collate keys in replication queue ---------------------------------- Key: ISPN-503 URL: https://jira.jboss.org/browse/ISPN-503 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 4.1.0.BETA2 Reporter: Mircea Markus Assignee: Manik Surtani At the moment the replication queue is replicating all the keys. What it can do is to collate them, similar to the way cache stores are collating writes. E.g. 1. put(k,v1) 2. put(k,v2). This can be collated in put(k,v2), as put(k,v1) is redundant. This would optimize async replication in a way that cannot be handled by jgroups. -- 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, 2 months

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-159) Extended coalesced logic to other parts

by Galder Zamarreno (JIRA)

Extended coalesced logic to other parts --------------------------------------- Key: ISPN-159 URL: https://jira.jboss.org/jira/browse/ISPN-159 Project: Infinispan Issue Type: Feature Request Components: RPC, Transactions Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR1 Reuse same coalesced async cache store logic to: - Reduce size of replicable commands where N modifications are sent so that only latest state is sent. - Manage the async replication queue. -- 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, 2 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-330) Separate scheduled/unscheduled async cache store configuration

by Galder Zamarreno (JIRA)

Separate scheduled/unscheduled async cache store configuration -------------------------------------------------------------- Key: ISPN-330 URL: https://jira.jboss.org/jira/browse/ISPN-330 Project: Infinispan Issue Type: Sub-task Components: Configuration, Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement configuration that allows differentiation between scheduled/unscheduled strategies: <async enabled="true"> <scheduled frequency="1000" /> </async> <async enabled="true"> <unscheduled poolsize="50" /> </async> This format allows for easier extension of properties in scheduled/unscheduled modes. -- 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, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-939) Index corruption when remote node dies during commit

by Tristan Tarrant (JIRA)

Index corruption when remote node dies during commit ---------------------------------------------------- Key: ISPN-939 URL: https://issues.jboss.org/browse/ISPN-939 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.1.CR2 Reporter: Tristan Tarrant Assignee: Sanne Grinovero Using a scenario similar to the one described in ISPN-909: Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction, hash numOwners=2) Node 1: coordinator, IndexWriter open constantly and writing a stream of documents, committing after each one Node 2: opens a read-only IndexReader to perform queries, using reopen to keep in sync with the updates coming from node 1 If we "kill -9" node 2 (to simulate a crash), we get a SuspectException in node 1 during the pre-commit phase (within IndexWriter.commit()). Catching the Throwable we then close() the writer but from then on we get "Read past EOF" errors when trying to access the index (both with readers and writers). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
20
0 / 0

[JBoss JIRA] Created: (ISPN-469) HotRod client in .NET

by Manik Surtani (JIRA)

HotRod client in .NET --------------------- Key: ISPN-469 URL: https://jira.jboss.org/browse/ISPN-469 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final .NET client impl for HotRod. Protocol is documented here: http://community.jboss.org/wiki/HotRodProtocol Could be based off the Java reference impl client: http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-557) support for same transaction touching multiple nodes (multiple VMs)

by Mircea Markus (JIRA)

support for same transaction touching multiple nodes (multiple VMs) -------------------------------------------------------------------- Key: ISPN-557 URL: https://jira.jboss.org/browse/ISPN-557 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final E.g. if a distributed transaction managers touches two embedded Infinispan nodes within the same transaction. Could be implemented using the Hot Rod client approach - but in an embedded fashion! EmbeddedClient <-- implements logic above Except comms are in-VM for local entries And via RpcDispatcher for remote entries RemoteClient extends EmbeddedClient Adds proper HotRod layer for comms Including failover, smart routing, 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

12 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-848) Enhance HotRod to allow explicit locking of keys

by Erik Salter (JIRA)

Enhance HotRod to allow explicit locking of keys ------------------------------------------------ Key: ISPN-848 URL: https://issues.jboss.org/browse/ISPN-848 Project: Infinispan Issue Type: Feature Request Reporter: Erik Salter Assignee: Manik Surtani Hot Rod clients should allow explicit locking of keys, especially useful for the "find-for-update" design pattern. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2011