March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-162) Add a brief AS clustering overview

by Brian Stansberry (JIRA)

Add a brief AS clustering overview ---------------------------------- Key: JBCLUSTER-162 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-162 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q2Y7 To appear after the JBC material, before EJB3. Some contents: 1) Reiterate locations of config files. 2) Configuration startup switches; -b -g -u etc. 3) Multiplexer discussion. -- 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, 4 months

2
1
0 / 0

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

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-86?page=all ] Brian Stansberry updated JBCLUSTER-86: -------------------------------------- Fix Version/s: Q3Y7 (was: Q2Y7) > 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: Q3Y7 > > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-113) WSAS Http Session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-113?page=all ] Brian Stansberry updated JBCLUSTER-113: --------------------------------------- Fix Version/s: (was: Q2Y7) > WSAS Http Session replication using JBossCache > ---------------------------------------------- > > Key: JBCLUSTER-113 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-113 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > > Similar to JBCLUSTER--112, but for Websphere. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-112) WL http session repl using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-112?page=all ] Brian Stansberry updated JBCLUSTER-112: --------------------------------------- Fix Version/s: (was: Q1Y7) > WL http session repl using JBossCache > ------------------------------------- > > Key: JBCLUSTER-112 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-112 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > > WL http session fine-grained replication using JBossCache > Goal: > To use one single pluggable JBoss web clustering module to run JBoss, Tomcat (standalone), and Weblogic http session replication. Right now, both JBoss and Tomcat standalone has used the same module to perform session replication. Currently, we have options of using different replication granularity: SESSION, ATTRIBUTE, and FIELD where FIELD is the fine-grained replication using TreeCacheAop (aka POJO Cache). What is left is Weblogic one. Although Weblogic has itself a replication layer, use of JBossCache is still attractive because no expensive clustering licensing is needed! > Possible steps need to be done: > 1. Weblogic has an option of allowing a user to specify a session persistence manager (to file, e.g.). This is where other caching solutions used to hook into WL. We should do the same using JBossCache. However, the exact steps need to be determined. > 2. Determine the necessary Manager interface that is needed to unify all 3 solutions. Currently, both in JBoss and Tomcat, we have a notion of Manager and Session interface. Session should be relatively standard. But Manager is Tomcat specific. We will need to investigate on the possibility for extension. > 3. Tomcat uses Valve to create the replication trigger. Need to find a way to do that in WL. How about filter? > 4. Determine the necessary configuration. Currently in JBoss, we allow to have useJK flag for mod_jk specific failover. Solution in WL should work the same. And so is the session replication granularity. > 5. JBossCache startup. Weblogic has a startup class that should allow JBossCache to start up as a singleton and for later lookup. Under JBoss, JBossCache is run as a MBean. > 6. Management attributes. Currently, we are developing JBoss Cache JMX attribute management in 1.3. We will also need to add http session replication management layer as well to be used by all 3 solutions. > 7. Performance benchmarking. When it is completed, we will need to conduct extensive benchmarking. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-97) Integrated Replication for EJB3 and HttpSession

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-97?page=all ] Brian Stansberry updated JBCLUSTER-97: -------------------------------------- Fix Version/s: Q4Y7 (was: Q1Y7) Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, Compatibility/Configuration] (was: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration, Interactive Demo/Tutorial]) > Integrated Replication for EJB3 and HttpSession > ----------------------------------------------- > > Key: JBCLUSTER-97 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-97 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: Q4Y7 > > > We need to have the ability to replicate any EJB3 and http session state changes associated with a request at the same time. Otherwise, we just double the replication-related latency of the request. This is critical in the case of SEAM. -- 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, 4 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-54?page=all ] Brian Stansberry updated JBCLUSTER-54: -------------------------------------- Fix Version/s: Q4Y7 (was: Q1Y7) > 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: Q4Y7 > > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-69) Create an analysis comparing HttpSession replication in JBoss to BEA's implementation

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-69?page=all ] Brian Stansberry updated JBCLUSTER-69: -------------------------------------- Fix Version/s: Q3Y7 (was: Q1Y7) > Create an analysis comparing HttpSession replication in JBoss to BEA's implementation > ------------------------------------------------------------------------------------- > > Key: JBCLUSTER-69 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-69 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: Q3Y7 > > > We need to compare the features/capabilities of our session replication approach to BEA's. The results of the analysis should be a driver for the session replication roadmap. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-68) enhance farm deployment to handle cluster partitioning and merging

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-68?page=all ] Brian Stansberry resolved JBCLUSTER-68. --------------------------------------- Fix Version/s: (was: Q1Y7) Resolution: Duplicate Issue Scott, I'm going to close this JIRA; let's just track anything we decide to do on it via JBAS-2326. > enhance farm deployment to handle cluster partitioning and merging > ------------------------------------------------------------------ > > Key: JBCLUSTER-68 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-68 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott Marlow > Assigned To: Scott Marlow > Priority: Optional > > Handle partitions and merges. Here's a use case: > * Group is {A,B,C,D,E} > * Partition occurs > * Groups are now {A,B,C} and {D,E} > * User drops WAR into E > * D and E will have WAR > * Partition heals, merge occurs > o Group is now {A,B,C,D,E} > * A,B,C don't have the WAR, D and E have it > We could possibly use the same algorithm we use to reconcile this when D > and E were offline and a user dropped the WAR into E's ./farm dir. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-88) Cluster configuration wizard

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-88?page=all ] Brian Stansberry updated JBCLUSTER-88: -------------------------------------- Fix Version/s: Q3Y7 (was: Q1Y7) > Cluster configuration wizard > ---------------------------- > > Key: JBCLUSTER-88 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-88 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Brian Stansberry > Fix For: Q3Y7 > > > Maybe in collaboration with JBoss Network (or maybe they are working on it). > - Tool to configure clustering, generates e.g. cluster-service.xml file > - First pick what needs to be clustered, e.g. base clustering (HA-JNDI etc), HTTP session replication, clustered EJB3 etc > - Then, for each cluster, configure: > - what transport (default) > - what bind address (tool should probe for NIC and display them in a list) > - for TCP: list of nodes > - If TCP: no FRAG, no UNICAST > - If UDP: what mcast address, TTL, port > - Wizard should run sanity tests after config, e.g. are clusters cleanly separated ? > - Wizard should provide defaults, so pressing Enter on every decision leads to the default clustering config > - Wizard should also be able to parse existing config, and reconfig 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, 4 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-40) Support for ejb3 SFSB passivation using JBossCache overflowing

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-40?page=all ] Brian Stansberry resolved JBCLUSTER-40. --------------------------------------- Resolution: Done > Support for ejb3 SFSB passivation using JBossCache overflowing > -------------------------------------------------------------- > > Key: JBCLUSTER-40 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-40 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently, SFSB has its own activation/passivation policy on top of JBossCache. When JBossCache supports its own activation/passivation policy, we should port it to ejb3. -- 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, 4 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 March 2007