February 2009 - jbosscache-issues

[JBoss JIRA] Updated: (JBCACHE-1128) Automated integration testing to ensure compatibility of dependencies

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1128?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1128: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Automated integration testing to ensure compatibility of dependencies > --------------------------------------------------------------------- > > Key: JBCACHE-1128 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1128 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Scripts and processes > Reporter: Brian Stansberry > Assignee: Manik Surtani > Priority: Minor > Fix For: 3.2.0.GA > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The component-info.xml that goes into repository.jboss.org should be coming from the JBC source tree. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1011) Component to calculate the memory footprint of elements in the cache

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1011?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1011: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Component to calculate the memory footprint of elements in the cache > -------------------------------------------------------------------- > > Key: JBCACHE-1011 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1011 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 3.2.0.GA > > > As with Java5 java offers support for determining the size of objects. An memory based eviction policy can be written for this java version only. The basic idea is to let the user to specify the amount of memory he wants to use. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-841) Be able to set the internal ordering of child nodes and data keys

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-841?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-841: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Be able to set the internal ordering of child nodes and data keys > ----------------------------------------------------------------- > > Key: JBCACHE-841 > URL: https://jira.jboss.org/jira/browse/JBCACHE-841 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Elias Ross > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > Attachments: OrderedNode.java > > > I believe that this issue is required to resolve JBCACHE-166 satisfactorily. > But it would also be a useful (and easily added) feature for JBossCache 2.0. > The attached .java file explains two additional methods to add. > The internal implementation would likely need to rely on the JDK1.6 java.util.concurrent.ConcurrentSkipListSet and Map implementations to work without change to other code that rely on iteration to work on concurrently modified sets. > As JDK 1.6 is new, this might require use of http://dcl.mathcs.emory.edu/util/backport-util-concurrent/doc/api/ for now, or support from the jbossretro to change these JDK1.6 classes to use the backport for 1.5. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1440) Better perfoming cache loader for JDBM

by Elias Ross (JIRA)

Better perfoming cache loader for JDBM -------------------------------------- Key: JBCACHE-1440 URL: https://jira.jboss.org/jira/browse/JBCACHE-1440 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani Patch to add JdbmCacheLoader2 This non-backwards compatible version fixes some performance issues with getChildNames(), stores an entire Map not just a key. The store Map not key structure more naturally matches the granularity of cache loader operations. (For post 3.0 release I think.) -- 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, 10 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1380) Add UML output to javadocs

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1380?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1380: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Add UML output to javadocs > -------------------------- > > Key: JBCACHE-1380 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1380 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Scripts and processes > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Fix For: 3.2.0.GA > > > Either yDocs - for which we have an OSS license - or Trustin's APIViz. > http://code.google.com/p/apiviz/ > Pros and cons are that APIViz is F/OSS but requires that you have graphviz installed on the build system. yDocs needs a license and even though we have an OSS license for it, we can't package or distribute it. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1240) Option to create another copy of backup data if data owner dies

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1240?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1240: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Option to create another copy of backup data if data owner dies > --------------------------------------------------------------- > > Key: JBCACHE-1240 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1240 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Buddy Replication > Reporter: Brian Stansberry > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > With BR, if a data owner dies, the number of copies of the data it owns is reduced by one. If the data is accessed, another node becomes owner and the number of backups returns to normal. But if the data isn't accessed, the number of backups remains reduced. > Besides the general problem of lesser reliability for this data, this can be a problem with things like rolling upgrades, where all the backup nodes could be restarted before the data is accessed, leading to data loss. > Downside to making another copy of the backup data when the owner dies is it adds stress to the system by replicating more data. So, this should be configurable. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1262) Refactor TcpCacheServer to use Executor framework

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1262?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1262: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Refactor TcpCacheServer to use Executor framework > ------------------------------------------------- > > Key: JBCACHE-1262 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1262 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > A more robust approach to the current spawning of threads would be to use Java5's executor framework. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1407) Region-based marshalling to support multiple regions in a PREPARE.

by Brian Stansberry (JIRA)

Region-based marshalling to support multiple regions in a PREPARE. ------------------------------------------------------------------ Key: JBCACHE-1407 URL: https://jira.jboss.org/jira/browse/JBCACHE-1407 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Reporter: Brian Stansberry Assignee: Manik Surtani A transaction can operate on multiple regions within a cache, so the resulting PREPARE will include data from multiple regions. But the region-based marshalling logic will identify a single region Fqn for the message (first one it finds); result is data from other regions will not unmarshall properly. Region-based marshalling needs to be able to handle such a case; analyze the prepare and create a separate region-fqn/data pair for each time the region changes. Storing the node's data in an org.jboss.cache.marshall.MarshalledValue doesn't solve the problem, as in use cases like Hibernate, custom types can be part of the Fqn (below the region root.) -- 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, 10 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBCACHE-789) TCPCacheLoader that can use a load balanced proxy

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-789?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-789: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > TCPCacheLoader that can use a load balanced proxy > ------------------------------------------------- > > Key: JBCACHE-789 > URL: https://jira.jboss.org/jira/browse/JBCACHE-789 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Reporter: Brian Stansberry > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > Using cache mode LOCAL and a DelegatingCacheLoader (aka a far-cache) has the potential to be a very performant cluster topology. But, the far cache is a single point of failure. Idea here is to develop an HA proxy to a cluster of far-caches; proxy pins to one far-cache, but can fail over to another if the primary target fails. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1442) Improve performance with "Cache.setData" call

by Elias Ross (JIRA)

Improve performance with "Cache.setData" call --------------------------------------------- Key: JBCACHE-1442 URL: https://jira.jboss.org/jira/browse/JBCACHE-1442 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani For a configuration that uses an async cache loader in 3.0, performance of "put(Map m)" may be unexpectedly slow. This is because put(Map) is a merge call and always results in a load. Imagine if put(Map) is being done over the network, e.g. JDBC database. This is not want users would expect. And there's no alternative to this in the current API set. (The work-around is to have cache calls done using a thread pool...) Cache.getNode(X).replaceAll() won't work as it results in a load, and/or a null pointer exception if the node is not found. The old TreeCache from 1.4 had a "put erase" option. I suggest we create a setData() method that does not do a merge. Changes are attached, with some new tests, but I'm not sure the implementation is really complete. The tests set "goals" for the proper behavior of the cache loader. -- 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, 10 months

2
3
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