July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-503) Coalesce updates in the replication queue

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-503?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-503: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Coalesce updates in the replication queue > ----------------------------------------- > > Key: ISPN-503 > URL: https://issues.jboss.org/browse/ISPN-503 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 4.1.0.BETA2 > Reporter: Mircea Markus > Assignee: Galder Zamarreño > > 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1988) Coalesce updates to a given key to a single operation within a transaction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1988?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1988: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Coalesce updates to a given key to a single operation within a transaction > -------------------------------------------------------------------------- > > Key: ISPN-1988 > URL: https://issues.jboss.org/browse/ISPN-1988 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.1.4.FINAL > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: optimisation, transaction > > Following code run with optimistic caches: > start tx > put k, v1 > put k, v2 > put k, v3 > commit > Would cause the PrepareCommand that is sent around to contain 3 PutKeyvalueCommands which is sub-optimal. What we can do is to only send the last written value (i.e. k v3) and ignore the previous two (reuse the code in AsyncCacheStore). Besides reducing the payload, from this would benefit the AtomicHashMaps which uses this code quite a lot and also the OptimisticLockingInterceptor which would not attempt to order the keys. > I guess this should be a feature that is disabled by default, as I don't think it is required in general. Might as well be not configurable, enabled by default feature. Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2230) Commented configurations should be tested for warnings

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2230?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2230: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Commented configurations should be tested for warnings > ------------------------------------------------------ > > Key: ISPN-2230 > URL: https://issues.jboss.org/browse/ISPN-2230 > Project: Infinispan > Issue Type: Task > Components: Configuration > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Commented cache configurations in etc/config-samples/sample.xml contain deprecated options. > Find a way to test these configurations for warnings while maintaining them commented in the distribution. > Clearly, make sure any deprecated elements are removed in these configurations and convert them to the new options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1419) Clean up ConfigurationOverrides to match what 5.1 supports

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1419?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1419: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Clean up ConfigurationOverrides to match what 5.1 supports > ---------------------------------------------------------- > > Key: ISPN-1419 > URL: https://issues.jboss.org/browse/ISPN-1419 > Project: Infinispan > Issue Type: Enhancement > Components: Spring integration > Affects Versions: 5.1.0.ALPHA2 > Reporter: Marius Bogoevici > Assignee: Marius Bogoevici > > Currently, ConfigurationOverrides is accessing Configuration directly through a series of deprecated methods. Make this fully compatible with Infinispan 5.1 and use FluentConfiguration instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1791) Change of numOwners during runtime

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1791?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1791: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Change of numOwners during runtime > ---------------------------------- > > Key: ISPN-1791 > URL: https://issues.jboss.org/browse/ISPN-1791 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.1.0.FINAL > Reporter: Thomas Fromm > Assignee: Manik Surtani > > When the number of nodes increases, I want to increase/decrease the number of numOwners at DIST too. > For me one or both of the following options would be nice: > 1) Additional to numOwners an attribute "numOwnersRatio". When numOwners is set, the numOwners value is used as minimum number of owners. If the ratio results into a higher number, this value is used. > e.g. numOwners = 2, numOwnersRatio = 0.5; In case of 3 nodes inside the cluster, the numOwners value of 2 is used. 5 nodes => 3 owner, 8 nodes => 4 owners... > 2) Simply change the numOwners setting programmatic via API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1301) Check hashKeyMask of FIleCacheStore

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1301?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1301: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Check hashKeyMask of FIleCacheStore > ----------------------------------- > > Key: ISPN-1301 > URL: https://issues.jboss.org/browse/ISPN-1301 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Affects Versions: 5.0.0.CR8 > Reporter: Robert Stupp > Assignee: Manik Surtani > > Related to ISPN-1300: > If the configured "hashKeyMask" value is changed for an existing cache store, the whole cache store becomes unusable. > Parts of the cache store configuration should be persisted in the file cache store and checked upon startup. > If the existing (persistent) configuration is different from what the user has set in the configuration XML (or programatically), two things are possible: > 1. print a WARNING that the cache store uses the persistent configuration > 2. like 1, but perform a re-hash of the file cache store, if a certain configuration option has been set -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3237) Check if the lock acquisition can be removed for remote fetch entries in optimistic caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3237?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3237: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > Check if the lock acquisition can be removed for remote fetch entries in optimistic caches > ------------------------------------------------------------------------------------------ > > Key: ISPN-3237 > URL: https://issues.jboss.org/browse/ISPN-3237 > Project: Infinispan > Issue Type: Enhancement > Components: Locking and Concurrency, Transactions > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: locking > > When a remote get is performed, it tries to lock the key in the originator. However: > * the originator is not an owner, so nothing will be locked > * in optimistic caches, the lock should be only acquired in the prepare phase -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3193) Capture time budgeting information

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3193?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3193: ------------------------------------- indeed it looks very helpful. > Capture time budgeting information > ---------------------------------- > > Key: ISPN-3193 > URL: https://issues.jboss.org/browse/ISPN-3193 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Minor > Labels: diagnostics, performance > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > Should be most recent timing for each major subsystem for each type of call. E.g., > PUT: 10ms (locking), 10ms (datacontainer), 20ms (RPC), 30ms (CacheStore). > GET: 0ms (locking), 5ms (datacontainer), 0ms (RPC), 10ms (CacheStore). > etc. > Could be implemented as a simple ringbuffer, in a specific component (TimeBudgetMonitor?) just storing the most recent N calls and that's it. Cheap to capture, cheap to store. > This data could then be made available via a JMX operation on TimeBudgetMonitor. This is extremely valuable for tuning and debugging perf issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3193) Capture time budgeting information

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3193?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3193: -------------------------------- Fix Version/s: (was: 6.0.0.Final) (was: 6.0.0.Alpha1) > Capture time budgeting information > ---------------------------------- > > Key: ISPN-3193 > URL: https://issues.jboss.org/browse/ISPN-3193 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Minor > Labels: diagnostics, performance > > Should be most recent timing for each major subsystem for each type of call. E.g., > PUT: 10ms (locking), 10ms (datacontainer), 20ms (RPC), 30ms (CacheStore). > GET: 0ms (locking), 5ms (datacontainer), 0ms (RPC), 10ms (CacheStore). > etc. > Could be implemented as a simple ringbuffer, in a specific component (TimeBudgetMonitor?) just storing the most recent N calls and that's it. Cheap to capture, cheap to store. > This data could then be made available via a JMX operation on TimeBudgetMonitor. This is extremely valuable for tuning and debugging perf issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2826) CacheQuery.list() returns List<Object>, which is hard to cast

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2826?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2826: -------------------------------- Fix Version/s: 6.0.0.Beta1 > CacheQuery.list() returns List<Object>, which is hard to cast > ------------------------------------------------------------- > > Key: ISPN-2826 > URL: https://issues.jboss.org/browse/ISPN-2826 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Ray Tsang > Assignee: Adrian Nistor > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > In example for Books in https://docs.jboss.org/author/display/ISPN/Querying+Infinispan > ~~ snip snip ~~ > CacheQuery query = searchManager.getQuery(luceneQuery, Book.class); > // and there are your results! > List<Book> objectList = query.list(); > ~~ snip snip ~~ > This doesn't actually work. CacheQuery.list() returns List<Object> > Thus, you will need to cast: List<Book> books = (List<Book>) cq.list(); > But this wouldn't work... Instead you'll end up doing: List<Book> books = (List<Book>)(List<?>) cq.list(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013