March 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Updated: (ISPN-3) Should use JGroups scoping

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-3?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-3: ----------------------------- Fix Version/s: 5.2.0.Final (was: 5.0.0.BETA1) (was: 5.0.0.Final) > Should use JGroups scoping > -------------------------- > > Key: ISPN-3 > URL: https://jira.jboss.org/jira/browse/ISPN-3 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 5.2.0.Final > > > JGroups will provide a scoping API. This allows better concurrency in the JGroups channel. By default, the scope used should be the cache name, although use of other scopes should be allowed such as GlobalTransaction. Also need to consider allowing arbitrary scopes, passed in by user code. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-20) check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-20: ------------------------------ Fix Version/s: 5.0.0.BETA1 5.0.0.Final (was: 4.1.0.BETA1) (was: 4.1.0.Final) > check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE > --------------------------------------------------------------------------------- > > Key: ISPN-20 > URL: https://jira.jboss.org/jira/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Locking and Concurrency > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Not sure whether the 'outside' locking (MVCC) can't be used so that we won't need locking code within cache stores -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-61) Transaction 2-phase protocol optimizations

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-61?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-61: ------------------------------ Summary: Transaction 2-phase protocol optimizations (was: Tx optimisations) Fix Version/s: 5.0.0.BETA1 5.0.0.Final (was: 4.1.0.BETA1) (was: 4.1.0.Final) Complexity: High > Transaction 2-phase protocol optimizations > ------------------------------------------ > > Key: ISPN-61 > URL: https://jira.jboss.org/jira/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-46) Feature comparison with other products

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-46?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-46: ------------------------------ Fix Version/s: 5.0.0.Final (was: 4.1.0.Final) (was: 4.1.0.CR1) Moving this to 5.0, it may well get done before that though. > Feature comparison with other products > -------------------------------------- > > Key: ISPN-46 > URL: https://jira.jboss.org/jira/browse/ISPN-46 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Manik Surtani > Fix For: 5.0.0.Final > > > Compare (feature wise) against other products: > - Coherence, Terracotta and gigaspaces, hadoop, mogileFS -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-29) Cache server and client module

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-29: ------------------------------ Priority: Blocker (was: Major) > Cache server and client module > ------------------------------ > > Key: ISPN-29 > URL: https://jira.jboss.org/jira/browse/ISPN-29 > Project: Infinispan > Issue Type: Feature Request > Components: Cache Server > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Priority: Blocker > Fix For: 4.1.0.BETA1, 4.1.0.Final > > > To be built on top of the cache. > Transports should be pluggable - Initially XNIO, future community contribs using Apache MINA, Netty, JDK7 NIO2, native, etc. > Protocols should be pluggable - memcached text-based, custom binary with server topology information > Test with various memcached clients (java and non-java) > More details on this wiki page: > http://www.jboss.org/community/wiki/Clientandservermodules -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-367) Update memcached wikis

by Galder Zamarreno (JIRA)

Update memcached wikis ---------------------- Key: ISPN-367 URL: https://jira.jboss.org/jira/browse/ISPN-367 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.ALPHA1 Update the following 2 wikis after changes related to command line script (ISPN-353): http://community.jboss.org/docs/DOC-14644 http://community.jboss.org/docs/DOC-14773 -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-372) Create a plain Lucene LockFactory not using a TransactionManager

by Sanne Grinovero (JIRA)

Create a plain Lucene LockFactory not using a TransactionManager ---------------------------------------------------------------- Key: ISPN-372 URL: https://jira.jboss.org/jira/browse/ISPN-372 Project: Infinispan Issue Type: Task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.ALPHA2 -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-371) Update to Lucene 2.9.2

by Sanne Grinovero (JIRA)

Update to Lucene 2.9.2 ---------------------- Key: ISPN-371 URL: https://jira.jboss.org/jira/browse/ISPN-371 Project: Infinispan Issue Type: Task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.ALPHA2 -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-369) InvalidateL1Command should not be invoked if the keys are local

by Manik Surtani (JIRA)

InvalidateL1Command should not be invoked if the keys are local --------------------------------------------------------------- Key: ISPN-369 URL: https://jira.jboss.org/jira/browse/ISPN-369 Project: Infinispan Issue Type: Task Components: Distributed Cache Affects Versions: 4.0.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.ALPHA1, 4.1.0.Final InvalidateL1Command currently is broadcast cluster-wide (multicast) for the sake of efficiency. This means that even other owners will receive this command. The command's perform() method will prevent such owners from evicting the keys though, so this does not affect correctness. However it does affect performance since the command is still passed up the interceptor stack and, crucially, locks are acquired for the keys in question. A better solution would be for ReplicableCommand to expose a boolean shouldInvoke() method. By default this always returns true, but in the case of the InvalidateL1Command, the ownership of keys is checked here. The InboundInvocationHandler can then choose whether to invoke the command or not. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-311) CacheLoader.loadKeys(), and performance improvements when rehashing from a cache store

by Manik Surtani (JIRA)

CacheLoader.loadKeys(), and performance improvements when rehashing from a cache store -------------------------------------------------------------------------------------- Key: ISPN-311 URL: https://jira.jboss.org/jira/browse/ISPN-311 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA Rehashing can be improved a bit, specifically with the addition of something like CacheLoader.loadKeys(Set<Object> excludes). This will allow the rehash code to load just the necessary keys, excluding keys already considered from the data container directly, and then inspect each key to test if the key needs to be rehashed elsewhere. If so, the value could be loaded using load(), considering that as cluster sizes increase, rehashing would only affect a smaller percentage of overall data. -- 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, 1 month

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2010