February 2009 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1417) Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size

by Manik Surtani (JIRA)

Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size ---------------------------------------------------------------------------------------- Key: JBCACHE-1417 URL: https://jira.jboss.org/jira/browse/JBCACHE-1417 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA A few ideas here: Users could provide a min and max concurrency level, or a factor of number of nodes in the cache. Need to think of an efficient way to resize the lock collection without affecting ongoing operations. Would also need to consider intelligent collection monitoring to make sure hash functions spread nodes across the locks well, otherwise consider altering the hash function. -- 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

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1464) Ability to do bulk gets with TCPCacheLoader

by J B (JIRA)

Ability to do bulk gets with TCPCacheLoader ------------------------------------------- Key: JBCACHE-1464 URL: https://jira.jboss.org/jira/browse/JBCACHE-1464 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Reporter: J B Assignee: Manik Surtani Priority: Minor It would be great if one could make a bulk "get" call through the TcpCacheLoader, currently one has to make many call single calls to get data from the TcpCacheServer. It would be nice to be able to query in bulk for a list of Fqns. -- 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

15 years, 3 months

3
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1122) Be able to define regions using regular expressions

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1122?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1122: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Be able to define regions using regular expressions > --------------------------------------------------- > > Key: JBCACHE-1122 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1122 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Priority: Minor > Fix For: 3.2.0.GA > > > Particularly useful once we have regions as a top-level construct, with region-specific configuration. -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1388) benchmark against http://www.xstm.net/

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1388?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1388: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > benchmark against http://www.xstm.net/ > -------------------------------------- > > Key: JBCACHE-1388 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1388 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Scripts and processes > Environment: add http://www.xstm.net/ as a product to the cache benchmark framework > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 3.2.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1369) Investigate whether create() and destroy() public lifecycle methods are needed or whether start() and stop() alone will be sufficient.

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1369?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1369: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Investigate whether create() and destroy() public lifecycle methods are needed or whether start() and stop() alone will be sufficient. > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBCACHE-1369 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1369 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > See forum thread -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1371) Test for possible bug in TxInterceptor where a long running prepare executes simultaneously with a rollback on a different thread

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1371?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1371: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Test for possible bug in TxInterceptor where a long running prepare executes simultaneously with a rollback on a different thread > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBCACHE-1371 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1371 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transactions > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > The use case is when an async TM times out a transaction and rolls it back. The prepare may be in the process of acquiring locks, what happens to the rollback, and is the prepare thread properly interrupted? -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1233) Use XStream to serialize user classes as an option, to allow for replication between different versions of the app

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1233?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1233: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Use XStream to serialize user classes as an option, to allow for replication between different versions of the app > ------------------------------------------------------------------------------------------------------------------ > > Key: JBCACHE-1233 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1233 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.1.0.CR2 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > Deserialization failures (class definitions being changed) could be handled by re-playing the call, this time serializing using XStream which is more resilient to class definition changes. Perhaps a cfg option when the user is aware that class definitions have changed? -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1214) Can the cache be backed by LinkedHashSet instead of HashSet

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1214?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1214: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Can the cache be backed by LinkedHashSet instead of HashSet > ----------------------------------------------------------- > > Key: JBCACHE-1214 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1214 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: RFC > Reporter: Carl Shelbourne > Assignee: Manik Surtani > Priority: Optional > Fix For: 3.2.0.GA > > > Looking at the code it is noted that the cache is backed by a HashSet. > Would it be possible to change this so that it is backed by a LinkedHashSet. > There may or may not be performance benefits to this dependant on the usage. The primary reason for wanting it to be backed by a LinkedHashSet is the guaranteed ordering of the elements when iterated over. Having this guarantee would facilitate implementations of say a TableModel, but would make other iterations more predictable too. -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-471) Handle JGroups MERGE

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-471?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-471: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Handle JGroups MERGE > -------------------- > > Key: JBCACHE-471 > URL: https://jira.jboss.org/jira/browse/JBCACHE-471 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > When JGroups needs to do a merge due to a temporary break in the group structure, JGroups does not handle the merging of data. This is usually left up to the application to handle. > JBossCache should support pluggable merge policies, we could provide some simple merge policies and allow users to write their own. > 1. Evict on merge policy - when a merge occurs, evict the entire in-memory state. Useful for Hibernate or when used with a shared cache loader. > 2. Other merge algos ... ? -- 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

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1421) Optimize writes on primitives and Strings to short-circuit if there are no changes

by Manik Surtani (JIRA)

Optimize writes on primitives and Strings to short-circuit if there are no changes ---------------------------------------------------------------------------------- Key: JBCACHE-1421 URL: https://jira.jboss.org/jira/browse/JBCACHE-1421 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0 E.g., cache.put(fqn, "key", "Hello"); // tx 1 ... wait ... cache.put(fqn, "key", "Hello"); // tx 2 tx 2 should be able to short-circuit the process if there is no change in the payload. Only makes sense for primitives and Strings though. Even primitive arrays are not worth it since it would involve iterating through the array. -- 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

15 years, 3 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues February 2009