January 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-820) Resolve {@link} links in configuration reference

by Galder Zamarreño (JIRA)

Resolve {@link} links in configuration reference ------------------------------------------------- Key: ISPN-820 URL: https://jira.jboss.org/browse/ISPN-820 Project: Infinispan Issue Type: Feature Request Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic Fix For: 5.0.0.BETA1 Currently configuration reference documentation does not resolve {@link} links. It'd be nice if it'd point to the javadoc of the corresponding class if available! Examples: - Fully qualified class name of a class that looks up a reference to a {@link javax.transaction.TransactionManager}. The default provided is capable of locating the default TransactionManager in most popular Java EE systems, using a JNDI lookup. (Javadoc) - Fully qualified name of the class that the configured {@link org.infinispan.marshall.Externalizer} can marshall/unmarshall. Establishing the link between type marshalled and {@link org.infinispan.marshall.Externalizer} implementations enables users to provide their own marshalling mechanisms even for classes which they cannot modify or extend. (Javadoc) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
13
0 / 0

[JBoss JIRA] Created: (ISPN-767) Make deadlock detection run over multiple caches

by Mircea Markus (JIRA)

Make deadlock detection run over multiple caches ------------------------------------------------ Key: ISPN-767 URL: https://jira.jboss.org/browse/ISPN-767 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.2.0.Final right now deadlock detection runs on a per cache basis. Eg. following deadlock won't be detected: - N1,N2 two nodes, A and B are cache running on each of them. tx1 running on N1: N1.A.put(k1); N1.B.put(k2) tx2 running in N2: N2.B.put(k2); N2.A.put(k1) -- 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

11 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-445) Ensure that locks time out

by Phil vd (JIRA)

Ensure that locks time out -------------------------- Key: ISPN-445 URL: https://jira.jboss.org/browse/ISPN-445 Project: Infinispan Issue Type: Feature Request Components: Locking and Concurrency Reporter: Phil vd Assignee: Manik Surtani When a lock is acquired, no mechanism ensure that it is reclaimed later. So if for whatever reason the thread owning the lock is stuck in an endless loop or waiting for some resource, the entry is locked. This kind of situation could happen in cache stores trying to contact a remote storage. The risk is quite high that other entries may be locked as well if you use lock stripping (default : TRUE) -- 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

11 years, 6 months

5
5
0 / 0

[JBoss JIRA] Created: (ISPN-627) Provision to get Cache from CacheManager, without starting the Cache

by Girish Adat (JIRA)

Provision to get Cache from CacheManager, without starting the Cache -------------------------------------------------------------------- Key: ISPN-627 URL: https://jira.jboss.org/browse/ISPN-627 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 4.0.0.Final Reporter: Girish Adat Assignee: Manik Surtani Provision to getCache() from CacheManager, without starting the cache. This is for achieving scenarios like adding cache-listeners before starting the cache for first time. Adding a method getCache(String cacheName, boolean start) will work for the requirement. Also, any change in cache level configuration can be made programmatically by the client application, if this method is implemented. -- 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

11 years, 6 months

5
15
0 / 0

[JBoss JIRA] Created: (ISPN-506) Infinispan should have a notion of comparable dataversion for handling external db updates

by Max Rydahl Andersen (JIRA)

Infinispan should have a notion of comparable dataversion for handling external db updates ------------------------------------------------------------------------------------------ Key: ISPN-506 URL: https://jira.jboss.org/browse/ISPN-506 Project: Infinispan Issue Type: Feature Request Reporter: Max Rydahl Andersen Assignee: Manik Surtani As discussed in hotel bar -- 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

11 years, 6 months

6
18
0 / 0

[JBoss JIRA] Created: (ISPN-755) Provide API documentation for scala components within the distribution

by Richard Achmatowicz (JIRA)

Provide API documentation for scala components within the distribution ---------------------------------------------------------------------- Key: ISPN-755 URL: https://jira.jboss.org/browse/ISPN-755 Project: Infinispan Issue Type: Feature Request Affects Versions: 4.1.0.Final Reporter: Richard Achmatowicz Assignee: Manik Surtani Infinispan makes use of the Scala language to implement server modules for client-server communication. At present, these modules do not have any API documentation, which means that application developers must browse through the source code in order to find out which classes are available and what their interfaces are. Scala has the ability to produce scaladoc documentation, but this is not compatible with javadoc. It appears that there is no method at present to incorporate scala API information into existing javadoc documentation. The task of this issue is to investigate and implement a viable way to incorporate API information for the scala classes into the Infinispan distribution. -- 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

11 years, 6 months

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

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

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

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

11 years, 6 months

3
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2011