August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBCACHE-431) Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-431?page=all ] Manik Surtani closed JBCACHE-431. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Remove jboss-XXX JARs which contain Nested(Runtime)Exceptions > ------------------------------------------------------------- > > Key: JBCACHE-431 > URL: http://jira.jboss.com/jira/browse/JBCACHE-431 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1 > Reporter: Bela Ban > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-332) Webdav interface for accessing JBossCache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-332?page=all ] Manik Surtani closed JBCACHE-332. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Webdav interface for accessing JBossCache > ----------------------------------------- > > Key: JBCACHE-332 > URL: http://jira.jboss.com/jira/browse/JBCACHE-332 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > > Provide a webdav interface for JBossCache. This will enable access, e.g. from Windows Explorer. Any file dragged into a folder will be replicated across the cluster -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-328) Move attributes and getters/setters to interceptors

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ] Manik Surtani closed JBCACHE-328. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Move attributes and getters/setters to interceptors > --------------------------------------------------- > > Key: JBCACHE-328 > URL: http://jira.jboss.com/jira/browse/JBCACHE-328 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > > Example: currently IsolationLevel is an attribute of TreeCache. Goal is to make it an attribute of PessimisticLockingInterceptor. > Advantage:no unneeded methods in TreeCache, cluttering up the TreeCache class > #1 Implicit Configuration (conceptual) > -------------------- > <TreeCache> > <Replication> > <config> ... </config> > <mode>ASYNC</mode> > </Replication> > <IsolationLevel> > REPEATABLE-READ > </IsolationLevel> > </TreeCache> > This configures the interceptor chain > #2 Explicit configuration > ------------------------------------ > <TreeCache> > <Interceptor name="PessimisticLockingInterceptor" > class="xxxx" > level="REPEATABLE-READ" /> > <Interceptor>...</Interceptor> > </TreeCache> > The chain is defined explicitly, attributes are defines per interceptor > #3 JMX > If JMx is used, JBossCache is registered with the MBeanServer, and all interceptors are registered under JBossCache, e.g. > type=cache;name=JBossCache1 > type=cache;name=JBossCache1;interceptor_name=PessimisticLockingInterceptor > type=cache;name=JBossCache1;interceptor_name=CacheLoaderInterceptor > type=cache;name=JBossCache1;interceptor_name=ReplicationInterceptor > #4 Programmatic access > Can be done through JMX, but is not nice > cache.getIsolationLevel() --> ((PessimisticLockingInterceptor)cache.getInterceptor("PessimisticLockingInterceptor")).getIsolationLevel() -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-250) Hierarchical caches not working when using JBoss service

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ] Manik Surtani closed JBCACHE-250. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Hierarchical caches not working when using JBoss service > -------------------------------------------------------- > > Key: JBCACHE-250 > URL: http://jira.jboss.com/jira/browse/JBCACHE-250 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.3 > Reporter: Nimrod Rivier > Priority: Minor > > > I tried to configure a hierarchical cache, composed of a first-level memory-only cache, > and a second-level file-only cache. It seems not to work when I the caches are jboss services, > but works when I use plain classes. > Details: > The caches are created as follows: > TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server); > TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server); > LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance()); > sCacheFirstLevel.setCacheLoader(sCacheLoader); > I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel . > Adding the following did not help > sCacheFirstLevel.stopService(); > sCacheFirstLevel.startService(); > sCacheSecondLevel.stopService(); > sCacheSecondLevel.startService(); > When I use the following code to create the caches, everything seems to work fine: > sCacheSecondLevel = new TreeCache(); > sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader"); > Properties filecacheLoaderProperties = new Properties(); > filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests"); > sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties); > sCacheFirstLevel = new TreeCache(); > CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel); > sCacheFirstLevel.setCacheLoader(cacheLoader); > /* Configure the caches (removed) */ > sCacheSecondLevel.createService(); > sCacheSecondLevel.startService(); > sCacheFirstLevel.createService(); > sCacheFirstLevel.startService(); > > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-154) Ability to request cache statisics

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ] Manik Surtani closed JBCACHE-154. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Ability to request cache statisics > ---------------------------------- > > Key: JBCACHE-154 > URL: http://jira.jboss.com/jira/browse/JBCACHE-154 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Rich Dredge > > It would be very helpful to retrieve stats about certain regions of the cache such as: > - Hit/Miss ratio per region > - Access counts > - Number of nodes within a region -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-163) Consolidate jboss related libraries

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ] Manik Surtani closed JBCACHE-163. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Consolidate jboss related libraries > ----------------------------------- > > Key: JBCACHE-163 > URL: http://jira.jboss.com/jira/browse/JBCACHE-163 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently the jboss dependent packaging in JBossCache is a bit scattered. We use the packaging from jboss-head but they are different the packaing, say, jboss-4.0. > For example, jboss head recently split jboss-j2ee.jar into jboss-j2ee and jboss-j2se.jar of which has no interests to us at all. > Nonetheless, our dependency on jboss is very minimal now. So maybe we should think of consolidating all the jboss packaging into a single one? In theory, we should use the jboss packages from full release, like AS4.0.2. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-129) Ensure graceful handling of marshalling between different versions

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ] Manik Surtani closed JBCACHE-129. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Ensure graceful handling of marshalling between different versions > ------------------------------------------------------------------ > > Key: JBCACHE-129 > URL: http://jira.jboss.com/jira/browse/JBCACHE-129 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > > backwards compatibility -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-115) beforeEviction() callback

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-115?page=all ] Manik Surtani closed JBCACHE-115. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > beforeEviction() callback > ------------------------- > > Key: JBCACHE-115 > URL: http://jira.jboss.com/jira/browse/JBCACHE-115 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.1 > Reporter: Bela Ban > -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-35) Externalize the buffer queue size in LRUAlgorithm

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-35?page=all ] Manik Surtani closed JBCACHE-35. -------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Externalize the buffer queue size in LRUAlgorithm > ------------------------------------------------- > > Key: JBCACHE-35 > URL: http://jira.jboss.com/jira/browse/JBCACHE-35 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 1.2 > Reporter: Ben Wang > Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-131) Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ] Manik Surtani closed JBCACHE-131. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup > ----------------------------------------------------------------------------------------------------- > > Key: JBCACHE-131 > URL: http://jira.jboss.com/jira/browse/JBCACHE-131 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Jimmy Wilson > Priority: Minor > Attachments: TreeCache.zip > > > Given the following single, unshared cache loader use case in the TreeCache documentation: > "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store" > A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability. > I have modified TreeCache to handle this situation, and I will attach the modified code to this issue. -- 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

18 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2007