October 2008 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1422) Allow thread pools and executors to be injected via the RuntimeConfig

by Manik Surtani (JIRA)

Allow thread pools and executors to be injected via the RuntimeConfig --------------------------------------------------------------------- Key: JBCACHE-1422 URL: https://jira.jboss.org/jira/browse/JBCACHE-1422 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 To allow injection frameworks to programmatically inject thread pools/executors used by: 1. Async replication 2. Async cache listeners 3. Eviction timer -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1424) JDBCCacheLoader does not close ConnectionFactory

by Krzysztof Sobolewski (JIRA)

JDBCCacheLoader does not close ConnectionFactory ------------------------------------------------ Key: JBCACHE-1424 URL: https://jira.jboss.org/jira/browse/JBCACHE-1424 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: AdjListJDBCCacheLoader.java.patch Maybe I don't understand something, but I think this is a bug that the method AdjListJDBCCacheLoader.stop() closes the ConnectionFactory only if the config.getDropTable() option is set to true. I don't want to drop my table, but I want to close the ConnectionFactory (because C3P0 won't unregister itself and I get a MBean leak after restart of my component). My guess is that the try block was misplaced. -- 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, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1427) Check all configurations shipped, for correctness wrt schemas prior to GA

by Manik Surtani (JIRA)

Check all configurations shipped, for correctness wrt schemas prior to GA ------------------------------------------------------------------------- Key: JBCACHE-1427 URL: https://jira.jboss.org/jira/browse/JBCACHE-1427 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.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

15 years, 6 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1376) New configuration file format

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1376?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1376: ----------------------------------- Fix Version/s: 3.0.0.CR2 > New configuration file format > ----------------------------- > > Key: JBCACHE-1376 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1376 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 3.0.0.CR2, 3.0.0.GA > > > This is an umbrella task spanning several sub-tasks. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1372) Update LGPL headers on all src files.

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1372?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1372: ----------------------------------- Fix Version/s: 3.0.0.CR2 > Update LGPL headers on all src files. > ------------------------------------- > > Key: JBCACHE-1372 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1372 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Scripts and processes > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Fix For: 3.0.0.CR2, 3.0.0.GA > > > Should read as per the wiki: > http://wiki.jboss.org/wiki/JBossLGPLUsage -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1274) Ability to configure zero nodes in memory for a region

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1274?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1274: ----------------------------------- Fix Version/s: 3.0.0.CR1 Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration] (was: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)]) > Ability to configure zero nodes in memory for a region > ------------------------------------------------------ > > Key: JBCACHE-1274 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1274 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Affects Versions: 2.0.0.GA > Reporter: J B > Assignee: Mircea Markus > Priority: Minor > Fix For: 3.0.0.CR1, 3.0.0.GA > > > The ability to configure a region to have no nodes in memory. If you have a cache configured with a cacheloader and you for instance dont want a certain region to have any nodes in memory but just to load the data through the cacheloader. At the moment you cant set maxNodes=0, because this actually means, the region can grow to an unlimited size, so I would like the ability to be able to tell the cache that this region should have no nodes in memory. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1268) Allow disabling of eviction thread

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1268?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1268: ----------------------------------- Fix Version/s: 3.0.0.CR1 > Allow disabling of eviction thread > ---------------------------------- > > Key: JBCACHE-1268 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1268 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Brian Stansberry > Assignee: Manik Surtani > Fix For: 3.0.0.CR1, 3.0.0.GA > > > The eviction thread is just a convenience; it doesn't do anything that a thread managed by the application couldn't do. But, right now if you want to configure eviction you can't turn this thread off. We should support disabling the eviction thread by setting wakeupIntervalSeconds to 0. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1082) Optimise nodes for single elements

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1082?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1082: ----------------------------------- Fix Version/s: 3.0.0.CR2 > Optimise nodes for single elements > ---------------------------------- > > Key: JBCACHE-1082 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1082 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.0.0.CR2, 3.0.0.GA > > Attachments: ReplicatedPojoPerfTest.java, UnversionedNode.patch.txt > > > Many use cases just place a single object in a Node. Rather than going through the memory and performance penalties of using Maps for a single entry, we should: > 1) Create a reference to 2 Objects for key and value, as well as a Map. > 2) Only initialise/construct the Map if Node.putAll() is called, or when Node.put() is called with a second key/value pair > 3) Otherwise just hold the key/value pair as direct object refs. > Would affect UnversionedNode and WorkspaceNodeImpl. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-611) Optimize modification list before replication

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-611?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-611: ---------------------------------- Fix Version/s: (was: 3.0.0.GA) > Optimize modification list before replication > --------------------------------------------- > > Key: JBCACHE-611 > URL: https://jira.jboss.org/jira/browse/JBCACHE-611 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.GA, 1.3.0.SP1 > Reporter: Bela Ban > Assignee: Mircea Markus > > When we use transactions, all modifications (PUT,REMOVE) are bundled (keyed by TX-ID) and replicated on TX commit. > This is very inefficient if (a) we have many modifications in the TX scope and (b) if the modifications touched the same parts of the cache over and over again. > We need to optimize the modification list before replication. (This maybe enabled/disabled via an attribute). > Example: put(a/b/c) --> put(/a/b/c/d) --> remove(/a/b/c) --> put(a/b/c) should simply result in a PUT modification with *all* of the attributes of /a/b/c, so 1 modification instead of 4 ! > A general algorithm might be: > - Maintain a dirty-node map Map<FQN, status>) (= "dirty", "removed") > - On a put(FQN): add or set FQN to the map, set status="dirty" > - On a remove(FQN): set FQN in map to "removed", needs to mark all subnodes as well, so maybe the dirty-node map needs to be > a tree... > We might get rid of *constructing the modification lists during modifications*, and only populate the dirty-node map. The modification list could only be created at *TX commit time*, from the dirty-node map, e.g in the above example: PUT(a/b/c). > This only applies to pessimistic locking (does it ? can't we optimize optimistic locking in similar ways ?) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-48) TreeCacheListener that ships data with notification

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-48?page=com.atlassian.jira.plu... ] Manik Surtani resolved JBCACHE-48. ---------------------------------- Fix Version/s: (was: 3.0.0.GA) Resolution: Won't Fix > TreeCacheListener that ships data with notification > --------------------------------------------------- > > Key: JBCACHE-48 > URL: https://jira.jboss.org/jira/browse/JBCACHE-48 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 1.2 > Reporter: Bela Ban > Assignee: Manik Surtani > Original Estimate: 2 days > Remaining Estimate: 2 days > > Data are locked, callback carries *ref*, not *value* -- 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, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues October 2008