June 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Updated: (ISPN-66) Make NodeKey Externalizable and add Externalizer

by Galder Zamarreno (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-66?page=com.atlassian.jira.plugin... ] Galder Zamarreno updated ISPN-66: --------------------------------- Fix Version/s: 4.0.0.CR1 (was: 4.0.0.BETA1) Moving to next release since don't have time to include it for Beta1 > Make NodeKey Externalizable and add Externalizer > ------------------------------------------------ > > Key: ISPN-66 > URL: https://jira.jboss.org/jira/browse/ISPN-66 > Project: Infinispan > Issue Type: Task > Components: RPC > Reporter: Galder Zamarreno > Assignee: Galder Zamarreno > Priority: Minor > Fix For: 4.0.0.CR1 > > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-92) Upgrade to latest JBoss Marshaller 1.2 release

by Galder Zamarreño (JIRA)

Upgrade to latest JBoss Marshaller 1.2 release ---------------------------------------------- Key: ISPN-92 URL: https://jira.jboss.org/jira/browse/ISPN-92 Project: Infinispan Issue Type: Thirdparty Change Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.0.0.BETA1 -- 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, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-81) Moving VAM versioning to startObjectOutput and investigate cache store marshaller usage

by Galder Zamarreño (JIRA)

Moving VAM versioning to startObjectOutput and investigate cache store marshaller usage --------------------------------------------------------------------------------------- Key: ISPN-81 URL: https://jira.jboss.org/jira/browse/ISPN-81 Project: Infinispan Issue Type: Task Components: RPC Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 4.0.0.BETA1 Promote use of start/objectToObjectStream/finish rather than having multiple objectToObjectStream() calls, specially in cache stores. By promoting this use, we can move versioning in VAM from objectToObjectStream() to start and hence serialize less data. Finally, make a note on the marshaller javadoc so that users know how to use it efficiently in future. -- 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, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-86) InternalCacheValue/InternalCacheEntry optimization

by Mircea Markus (JIRA)

InternalCacheValue/InternalCacheEntry optimization -------------------------------------------------- Key: ISPN-86 URL: https://jira.jboss.org/jira/browse/ISPN-86 Project: Infinispan Issue Type: Feature Request Components: Core API Affects Versions: 4.0.0.BETA1 Reporter: Mircea Markus Assignee: Mircea Markus >From a IRC discussion with Manik: Right now an InternalCacheValue(ICV) is created from an InternalCacheEntry(ICE) by the CacheStore whenever we persist an entry: this is in order to avoid duplicate marshalling of the key. Same way, an InternalCacheEntry is created from an ICV whenever the value is unmarshalled. Avoid this unnecessary creation of objects by making ICE aggregate an ICV, and delegate all the state calls to it. Impl note: in order to allow delegation from ICE to ICV, make all the ICV's methods final. -- 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, 11 months

2
3
0 / 0

[JBoss JIRA] Resolved: (ISPN-68) ClusterGet - fix

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-68?page=com.atlassian.jira.plugin... ] Mircea Markus resolved ISPN-68. ------------------------------- Resolution: Done done > ClusterGet - fix > ---------------- > > Key: ISPN-68 > URL: https://jira.jboss.org/jira/browse/ISPN-68 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 4.0.0.ALPHA2 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1 > > > From an email sent by Manik on infinispan-dev: > ================================================== > Regarding direct loading from a cache loader in the ClusteredGetCommand, this is an issue since a) it does not acquire any locks to put this value back in the data container, and b) probably as a consequence of a), doesn't bother to put any looked up value in the data container at all. > This is inefficient since multiple CGCs on the same key (coming from different cache instances in a cluster) would cause the owning cache to load this several times repeatedly from a loader. > I see this problem with DIST since I use CGC to load an entry from a remote cache and if L1 caching is disabled on the requesting cache, multiple uses of an entry will result in this entry being read off a loader repeatedly. Which is no good. :-) > So I think the CGC's perform() method should actually be doing a cache.get() - or something very similar - where the entire interceptor chain is invoked and locks are acquired, entries moved to the data container if loaded, etc., and metrics on cache hits/misses properly updated. The challenges here are, of course: > 1. The ping-pong effect. So we need to make sure any clustered cache loader or the DistributionInterceptor do not try and load this from elsewhere in the cluster. Easily solved with the isOriginLocal flag on the context. > 2. Making sure we get an InternalCacheEntry and not just a value to return. This is trickier since ICEs are not exposed via public APIs at all. Perhaps we need a separate, non-replicable Command for this purpose - maybe a subclass of GetKeyValueCommand (GetCacheEntryCommand?) which (a) cannot be replicated and (b) will return the ICE. > So, CGC would create a GCEC and pass it up the interceptor chain, and retrieve the ICE from the GCEC after the call returns? > ============================================= > This JIRA is about implementing 2nd suggestion as per description. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (ISPN-12) Optimize transactions spanning caches from the same cache manager

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-12?page=com.atlassian.jira.plugin... ] Mircea Markus resolved ISPN-12. ------------------------------- Resolution: Won't Fix After a discussion on the mailing list, we decided that this is rather on edge optimization (it won't work well for DIST or heterogenous caches,e.g. ASYNC_REPL and SYNC_REPL), and hence it will be dropped. More details on the discussion here: http://lists.jboss.org/pipermail/infinispan-dev/2009-June/000308.html > Optimize transactions spanning caches from the same cache manager > ----------------------------------------------------------------- > > Key: ISPN-12 > URL: https://jira.jboss.org/jira/browse/ISPN-12 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > Transactions that span caches on the same cache manager can be optimized by bundling their RPC calls (prepare, commit, rollback) together. Right now they would be separate RPC messages for each cache. > Need to think about how best to implement this. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-56) Create migration script for EHCache

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-56?page=com.atlassian.jira.plugin... ] Manik Surtani reassigned ISPN-56: --------------------------------- Assignee: Christophe Hivert (was: Adrian Cole) > Create migration script for EHCache > ----------------------------------- > > Key: ISPN-56 > URL: https://jira.jboss.org/jira/browse/ISPN-56 > Project: Infinispan > Issue Type: Sub-task > Components: Configuration, Migration tools > Reporter: Manik Surtani > Assignee: Christophe Hivert > Fix For: 4.0.0.BETA1, 4.0.0.GA > > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-25) JGroups ships with an XSD schema. Use this schema when validating configurations.

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-25?page=com.atlassian.jira.plugin... ] Manik Surtani commented on ISPN-25: ----------------------------------- Trunk now depends on JGroups 2.8.0.Beta1 > JGroups ships with an XSD schema. Use this schema when validating configurations. > ---------------------------------------------------------------------------------- > > Key: ISPN-25 > URL: https://jira.jboss.org/jira/browse/ISPN-25 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, RPC > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 4.0.0.BETA1, 4.0.0.GA > > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-61) Tx optimisations

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-61?page=com.atlassian.jira.plugin... ] Manik Surtani reassigned ISPN-61: --------------------------------- Assignee: Mircea Markus (was: Manik Surtani) > Tx optimisations > ---------------- > > 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: 4.0.0.BETA1, 4.0.0.GA > > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-61) Tx optimisations

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-61?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-61: ------------------------------ Fix Version/s: 4.0.0.BETA1 4.0.0.GA Affects Version/s: 4.0.0.ALPHA4 > Tx optimisations > ---------------- > > 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: Manik Surtani > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2009