March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (JBCLUSTER-19) JMX MBean clustering

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-19?page=all ] Ben Wang resolved JBCLUSTER-19. ------------------------------- Resolution: Out of Date > JMX MBean clustering > -------------------- > > Key: JBCLUSTER-19 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-19 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Minor > Fix For: Q1Y7 > > Original Estimate: 8 weeks > Remaining Estimate: 8 weeks > > Design and implement JMX MBean clustering using JBossCache. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-54) JGroups and JBoss Cache config best practice

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-54?page=all ] Ben Wang updated JBCLUSTER-54: ------------------------------ Assignee: Brian Stansberry (was: Ben Wang) > JGroups and JBoss Cache config best practice > -------------------------------------------- > > Key: JBCLUSTER-54 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-54 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Reporter: Michael Yuan > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > > We need a set of "Best Practices" on how to set various parameters on the JGroups and JBoss Cache MBean attributes. I think the "Best Practice" guide can take the format of a FAQ: > Q: Describe a common clustering error message or low performance scenario > A: Discuss possible reasons and MBean configuration parameters to adjust to solve this problem. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-86) Web container lacks cluster replication of application scope

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-86?page=all ] Ben Wang updated JBCLUSTER-86: ------------------------------ Assignee: Brian Stansberry (was: Ben Wang) > Web container lacks cluster replication of application scope > ------------------------------------------------------------ > > Key: JBCLUSTER-86 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-86 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Reporter: treespace > Assigned To: Brian Stansberry > Fix For: Q2Y7 > > > Replication of servlet contexts (a.k.a. appliction scope) are not supported by the servlet specification. That is an important fact that needs to be emphased in cluster related documentation. Applications need to be cluster-aware at some level so this is just another design issue that needs to be accomodated. > An extra-specification feature to cluster the servlet context would be peachy. Generalizing a shared object that hides the underlying cache implementation could provide a more portable alternative: > getServletContext().getAttribute(MAGIC_BEAN).setAttribute("myBroadcastMessage", "All your servlet contexts are belong to us!"); > To port the application you would need a port of the MAGIC_BEAN class to use whatever clustering facilities are available on the target platform. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-915) PojoCache will rollback concurrent transaction using optimistic locking

by Ben Wang (JIRA)

PojoCache will rollback concurrent transaction using optimistic locking ----------------------------------------------------------------------- Key: JBCACHE-915 URL: http://jira.jboss.com/jira/browse/JBCACHE-915 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.GA This is reported in the forum. Concurrent tx on any pojocache pojo will cause rollback under ALPHA1 release. This is clearly a drawback in the combination of PojoCache and optimistic locking becuase we create a new node under "_JBOSS_INTERNAL__" each time a pojo is created. Partial get around is to use Cache.getRegion() api as in this code snippet: String configFile = "META-INF/local-service.xml"; boolean toStart = false; cache_ = PojoCacheFactory.createCache(configFile, toStart); cache_.start(); cache_.getCache().getRegion(Fqn.fromString(REGION), true); This will trigger a region creation and subsquent pojocache operation under that region will be placed separately. -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-687) PojoCache to use aop 2.0 to bind interceptor dynamically

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-687?page=all ] Ben Wang updated JBCACHE-687: ----------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > PojoCache to use aop 2.0 to bind interceptor dynamically > -------------------------------------------------------- > > Key: JBCACHE-687 > URL: http://jira.jboss.com/jira/browse/JBCACHE-687 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.1.0.GA > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently in 2.0, I am introducing new field level interceptos such as SubjectInterceptor to emit the field events. However, make "introduction" to a POJO with a Subject interface also has the side effect of the interceptor will bind to that method jointpoint as well. This is not desirable. > Workaround is to check for MehtodInvocation is each field level interceptor or in AOP2.0, we can bind specifically to the Pointcut programmtically as discussed in the forum post. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-658) Fast locking for mostly-read PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ] Ben Wang updated JBCACHE-658: ----------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > Fast locking for mostly-read PojoCache > -------------------------------------- > > Key: JBCACHE-658 > URL: http://jira.jboss.com/jira/browse/JBCACHE-658 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Nitzan Niv > Assigned To: Ben Wang > Fix For: 2.1.0.GA > > > The locking mechanism locks all the nodes in the path from the tree root to the modified node. If the cache contains a deep hierarchy of nodes (e.g., PojoCache that contains complex objects) and the usage of the cache > is mostly-read the locking overhead is unnecessarilly large. > To enable REPEATABLE_READ isolation level with minimal overhead (but with reduced update parallelism) just the tree root should be locked instead of the nodes-path. To define this policy as a new isloation level ("single"): > Change in PessimisticLockInterceptor (line 199): > else { > if(isolation_level == IsolationLevel.SINGLE) {//XXX > if (i == 0) { > acquired=child_node.acquire(owner, lock_timeout, lock_type); > } > } else { > if(lock_type == DataNode.LOCK_TYPE_WRITE && i == (treeNodeSize - 1)) { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_WRITE); > } > else { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_READ); > } > }//XXX > } > in LockStrategyFactory.java: > if (lockingLevel == IsolationLevel.REPEATABLE_READ || lockingLevel == IsolationLevel.SINGLE) //XXX > return new LockStrategyRepeatableRead(); > and add the "SINGLE" isolation level to IsolationLevel.java. -- 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, 2 months

1
0
0 / 0

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

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-552?page=all ] Ben Wang updated JBCACHE-552: ----------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > 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) > Reporter: Ben Wang > Assigned To: Ben Wang > 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, 2 months

1
0
0 / 0

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

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-354?page=all ] Ben Wang updated JBCACHE-354: ----------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > 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: Ben Wang > 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBFORUMS-187) Pagination on ForumView sometimes shows more pages than it should

by Ryszard Kozmik (JIRA)

Pagination on ForumView sometimes shows more pages than it should ----------------------------------------------------------------- Key: JBFORUMS-187 URL: http://jira.jboss.com/jira/browse/JBFORUMS-187 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Priority: Minor Fix For: 1.0.0 GA, 1.0.1 RC Pagination on ForumView sometimes shows more pages than it should. It is strickly connected with Sticky and Annoucements topics. If there are more Stickies or Annoucememnts then page size then one more page is added which is wrong. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-903) Class file of ejb must exist in .jar file for it to deploy, this is wrong

by Bill Burke (JIRA)

Class file of ejb must exist in .jar file for it to deploy, this is wrong ------------------------------------------------------------------------- Key: EJBTHREE-903 URL: http://jira.jboss.com/jira/browse/EJBTHREE-903 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: Bill Burke Assigned To: William DeCoste Priority: Critical Fix For: AS 4.2.0 CR2 /lib/mdb-templates.jar /deploy/myejb.jar/ META-INF/ejb-jar.xml This deployment doesnt' work my bean classes are in a .jar in my lib/ directory. My ejb.jar only has a ejb-jar.xml file within it. -- 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, 2 months

2
1
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 March 2007