April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-741) Create a jdom replication GUI example

by Ben Wang (JIRA)

Create a jdom replication GUI example ------------------------------------- Key: JBCACHE-741 URL: http://jira.jboss.com/jira/browse/JBCACHE-741 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
10
0 / 0

[JBoss JIRA] Updated: (JBCACHE-485) Refactor the current Collection classes (list and set)

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-485?page=all ] Jason T. Greene updated JBCACHE-485: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Refactor the current Collection classes (list and set) > ------------------------------------------------------ > > Key: JBCACHE-485 > URL: http://jira.jboss.com/jira/browse/JBCACHE-485 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Critical > Fix For: PojoCache > > Attachments: icache.diff, set.diff > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > Current implementation of Collection uses direct coupling to the cache store indices. E.g., we map them into subtree according to index ordering. This is not very desirable for performance reason. We should consider to provide a indirect mapping such that it is considered a graph instead of ordered tree. > Or we should investigate whether it is possible to use a proxy operates on java.util.* classes such that we don't need to have our own implementation. The JDK lincense aside, ArrayList, e.g., uses an internal transient array. Is it possible to "aspectize" on that array only? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-354) PojoCache Collection proxy will keep track of the original reference

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-354?page=all ] Jason T. Greene updated JBCACHE-354: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache Collection proxy will keep track of the original reference > -------------------------------------------------------------------- > > Key: JBCACHE-354 > URL: http://jira.jboss.com/jira/browse/JBCACHE-354 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Original Estimate: 1 week > Remaining Estimate: 1 week > > When updating Collection proxy, we should also update the original local reference values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-473) Backward compability between releases

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-473?page=all ] Jason T. Greene updated JBCACHE-473: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Backward compability between releases > ------------------------------------- > > Key: JBCACHE-473 > URL: http://jira.jboss.com/jira/browse/JBCACHE-473 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > > Need to make sure what is a good framework to ensure backward binary compatability between releases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-585) PojoCache Collection class when detached, the in-memory fields are not updated

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-585?page=all ] Jason T. Greene updated JBCACHE-585: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache Collection class when detached, the in-memory fields are not updated > ------------------------------------------------------------------------------ > > Key: JBCACHE-585 > URL: http://jira.jboss.com/jira/browse/JBCACHE-585 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: PojoCache 2.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > This happens during the refactoring of Collections class (JBCACHE-580). For speed reason, I choose not to update it now. But we can make it configurable for performance optimization. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-206) PojoCache remote getObject needs to populate the in-memory reference as well

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-206?page=all ] Jason T. Greene updated JBCACHE-206: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache remote getObject needs to populate the in-memory reference as well > ---------------------------------------------------------------------------- > > Key: JBCACHE-206 > URL: http://jira.jboss.com/jira/browse/JBCACHE-206 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: PojoCache 2.2.0 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently, if we do a getObject from the remote node, it will create a new instance and attach that pojo instance with a CacheInterceptor such that all pojo operations will be intercepted and interact from the cache. However, we will also need to populate the in-memory copy as well such that when a removeObject is called (such that the pojo is detached from the cache), the pojo will still has the correct values. > Note this use case should be very rare. In general, if you do a removeObject, that usually means the pojos are ready for GCed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-157) Use privileged action in CacheInterceptor

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-157?page=all ] Jason T. Greene updated JBCACHE-157: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Use privileged action in CacheInterceptor > ----------------------------------------- > > Key: JBCACHE-157 > URL: http://jira.jboss.com/jira/browse/JBCACHE-157 > Project: JBoss Cache > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: 1.2.2 > Environment: Standalone JDK 1.5 application with custom security policy > Reporter: twundke > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Attachments: CacheInterceptor.patch > > > When using the AOP version of JBoss Cache in a security-managed environment, various classes require certain permissions (such as org.jboss.cache.aop.CachedType requiring java.lang.RuntimePermission "accessDeclaredMembers"). This also means that any class accessing a cached object must be granted these permissions. > There are a number of problems with this. The first is that it breaks the transparency of using AOP-ed objects with the cache, as users of these objects must be granted additional permissions. The second problem is the nature of the permissions that must be granted. They are powerful permissions that allow runtime reflection, and in my particular case cannot be granted to the code using cached objects. > The solution is to wrap the CacheInterceptor.invoke() method in a call to AccessController.doPrivileged() when a security manager is present. This allows the necessary permissions to be granted to the cache, without affecting the permissions of the calling code. > The attached patch does just that. However, I don't know if this will have an effect on using the cache within a managed environment. I suspect not, but have no way of testing this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-584) Investigate use of lazy mapping for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-584?page=all ] Jason T. Greene updated JBCACHE-584: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Investigate use of lazy mapping for PojoCache > --------------------------------------------- > > Key: JBCACHE-584 > URL: http://jira.jboss.com/jira/browse/JBCACHE-584 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.1.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Recent perf test on PojoCache shows bottleneck is on the initial mapping of putObject causing numerous trips to the local cache store. To optimize it further, either the TreeCache local mode need to be enhanced. Or one solution to this is the use of lazy mapping of the pojo. For example, when putObject is called, pojo is not mapped. Instead, it is stored under a "Serialized" state (can use JBossSerialization if pojo is not even Seriailizable) first. Then when the field is modified (detected from the CacheInterceptor), we will then map it lazily to the PojoCache store. > The performance gain can be had, if 1) initial saving of mapping, 2) field update is only selected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-318) CacheLoader persistent item should have an age limit

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-318?page=all ] Jason T. Greene updated JBCACHE-318: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > CacheLoader persistent item should have an age limit > ---------------------------------------------------- > > Key: JBCACHE-318 > URL: http://jira.jboss.com/jira/browse/JBCACHE-318 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently items that are persisted has no notion of age out. So let's say it is fairly common in SFSB to have the state not live more than 2 weeks in the store, for example. The other usage is when the cache crashed and the persistent store won't get cleaned up even when the items are orphaned. > Bela refused to put this functionality in the cache loader layer. So Manik's idea is to wrap around the object in the CacheStoreInterceptor with an additional timestamp. This way an offline thread can come in and clean them. > We can also check how does the current SFSB does this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-552) Use "/" to replace "__DEFAULT__" in eviction policy

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-552?page=all ] Jason T. Greene updated JBCACHE-552: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Use "/" to replace "__DEFAULT__" in eviction policy > --------------------------------------------------- > > Key: JBCACHE-552 > URL: http://jira.jboss.com/jira/browse/JBCACHE-552 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Came up with a suggestion from Bela's training course. Currently since the region specification is order important, so use of "/" can be dangerours if not specified correctly. Btu can we order it internally during eviction policy specification such that user can order them randomly? What's the implication for troubleshooting? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007