-
1. Re: Http sticky session in jboss 3.2.7
marinac Feb 26, 2006 12:31 PM (in response to marinac)This is my JBOSS-SERVICE.XML, where I did the changes.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server
PUBLIC "-//JBoss//DTD MBean Service 3.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-service_3_2.dtd">
<!-- $Id: jboss-service-50.xml,v 1.1.1.1.2.19 2004/11/10 06:16:50 starksm Exp $ -->
<!-- The JAAS security domain to use in the absense of an explicit
security-domain specification in the war WEB-INF/jboss-web.xml
-->
java:/jaas/other
<!-- Get the flag indicating if the normal Java2 parent first class
loading model should be used over the servlet 2.3 web container first
model.
-->
true
true
<!-- A flag indicating if the JBoss Loader should be used. This loader
uses a unified class loader as the class loader rather than the tomcat
specific class loader.
-->
true
<!--
Class of the session manager (used if context is marked as 'distributable'. Currently allowed values:
- org.jboss.web.tomcat.tc5.session.JBossCacheManager
-->
org.jboss.web.tomcat.tc5.session.JBossCacheManager
<!-- The name of the request attribute under with the authenticated JAAS
Subject is stored on successful authentication. If null or empty then
the Subject will not be stored.
-->
<!--
j_subject
-->
<!-- A flag indicating whether web-apps may set themselfs as privileged
in their custom WEB-INF/context.xml context configuration.
-->
false
<!-- The SessionIdAlphabet is the set of characters used to create a session Id
It must be made up of exactly 65 unique characters
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-*
-->
<!--
*******************************************************
****************** CLUSTERING *************************
*******************************************************
In order to activate HTTP Session clustering for Tomcat
make sure you run JBoss's "all" configuration i.e.
"run -c all"
(the default configuration doesn't contain clustering)
Furthermore, you may change SnapshotMode and
SnapshotInterval attributes below to indicate when to
synchronize changes with the other node(s).
If you use Apache+mod_jk(2) you will most probably use
the AJP1.3 connector below. Thus, if you so wish,
you may comment (i.e. deactivate) the HTTP connector
as it won't be used anymore.
*******************************************************
*******************************************************
*******************************************************
-->
<!--
If you are using clustering, the following two attributes
define when the sessions are replicated to the other nodes.
The default value, "instant", immediately replicates changes
to the other nodes after each request. In this case, the
"SnapshotInterval" attribute is not used.
The "interval" mode, in association with the "SnapshotInterval"
attribute, indicates that Tomcat will only replicates modified
sessions every "SnapshotInterval" miliseconds at most.
-->
instant
<!-- you must switch to "interval" to use this attribute (msec) -->
2000
<!--
DEPRECATED IN RELEASE 3.2.6.
A flag indicating if the local vm session value should be used if
it exists. When true, the existing vm local session values are used and
updates are replicated, but updates to the same session on other nodes
do not update the local session value. In the future release, we will
relax this restriction.
Note that this flag is needed because of scoped class loading. Since
each web app may have a different class loader, the session stored
in the distributed store are still serialzed version. So if this flag
is false, the session value is obtained from the distributed
cache for each access and there will be significant penalty for
performance.
For clustering purpose only.
-->
false
<!--
Whether to use MOD_JK(2) for load balancing with sticky session
combined with JvmRoute. If set to true, it will insert a JvmRouteFilter
to intercept every request and replace the JvmRoute if it detects a
failover. In addition, you will need to set the JvmRoute inside
Tomcat, e.g.,
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
in server.xml.
For clustering purpose only.
-->
true
jboss.web
<!-- A mapping to the server security manager service which must be
operation compatible with type
org.jboss.security.plugins.JaasSecurityManagerServiceMBean. This is only
needed if web applications are allowed to flush the security manager
authentication cache when the web sessions invalidate.
-->
<depends optional-attribute-name="SecurityManagerService"
proxy-type="attribute">jboss.security:service=JaasSecurityManager
<!--
Configuration for HTTP Session Clustering using JBossCache
-->
<!--
<depends optional-attribute-name="CacheName">jboss.cache:service=TreeCache
-->
jboss.cache:service=TomcatClusteringCache
jboss:service=TransactionManager
<!-- Only needed if the org.jboss.web.tomcat.tc5.jca.CachedConnectionValve
is enabled in the tomcat server.xml file
jboss.jca:service=CachedConnectionManager
--> -
2. Re: Http sticky session in jboss 3.2.7
marinac Feb 26, 2006 12:41 PM (in response to marinac)This is my jboss-service.xml:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE server PUBLIC "-//JBoss//DTD MBean Service 3.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-service_3_2.dtd"> <!-- $Id: jboss-service-50.xml,v 1.1.1.1.2.19 2004/11/10 06:16:50 starksm Exp $ --> <server> <mbean code="org.jboss.web.tomcat.tc5.Tomcat5" name="jboss.web:service=WebServer"> <!-- The JAAS security domain to use in the absense of an explicit security-domain specification in the war WEB-INF/jboss-web.xml--> <attribute name="DefaultSecurityDomain">java:/jaas/other</attribute> <!-- Get the flag indicating if the normal Java2 parent first class loading model should be used over the servlet 2.3 web container first model. --> <attribute name="Java2ClassLoadingCompliance">true</attribute> <attribute name="LenientEjbLink">true</attribute> <!-- A flag indicating if the JBoss Loader should be used. This loader uses a unified class loader as the class loader rather than the tomcat specific class loader. --> <attribute name="UseJBossWebLoader">true</attribute> <!-- Class of the session manager (used if context is marked as 'distributable'. Currently allowed values: - org.jboss.web.tomcat.tc5.session.JBossCacheManager--> <attribute name="ManagerClass">org.jboss.web.tomcat.tc5.session.JBossCacheManager</attribute> <!-- The name of the request attribute under with the authenticated JAAS Subject is stored on successful authentication. If null or empty then the Subject will not be stored. --> <!--<attribute name="SubjectAttributeName">j_subject</attribute>--> <!-- A flag indicating whether web-apps may set themselfs as privileged in their custom WEB-INF/context.xml context configuration.--> <attribute name="AllowSelfPrivilegedWebApps">false</attribute> <!-- The SessionIdAlphabet is the set of characters used to create a session Id It must be made up of exactly 65 unique characters <attribute name="SessionIdAlphabet">ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-*</attribute> --> <!-- ******************************************************* ****************** CLUSTERING ************************* ******************************************************* In order to activate HTTP Session clustering for Tomcat make sure you run JBoss's "all" configuration i.e. "run -c all" (the default configuration doesn't contain clustering) Furthermore, you may change SnapshotMode and SnapshotInterval attributes below to indicate when to synchronize changes with the other node(s). If you use Apache+mod_jk(2) you will most probably use the AJP1.3 connector below. Thus, if you so wish, you may comment (i.e. deactivate) the HTTP connector as it won't be used anymore. ******************************************************* ******************************************************* ******************************************************* --> <!-- If you are using clustering, the following two attributes define when the sessions are replicated to the other nodes. The default value, "instant", immediately replicates changes to the other nodes after each request. In this case, the "SnapshotInterval" attribute is not used. The "interval" mode, in association with the "SnapshotInterval" attribute, indicates that Tomcat will only replicates modified sessions every "SnapshotInterval" miliseconds at most. --> <attribute name="SnapshotMode">instant</attribute> <!-- you must switch to "interval" to use this attribute (msec) --> <attribute name="SnapshotInterval">2000</attribute> <!-- DEPRECATED IN RELEASE 3.2.6. A flag indicating if the local vm session value should be used if it exists. When true, the existing vm local session values are used and updates are replicated, but updates to the same session on other nodes do not update the local session value. In the future release, we will relax this restriction. Note that this flag is needed because of scoped class loading. Since each web app may have a different class loader, the session stored in the distributed store are still serialzed version. So if this flag is false, the session value is obtained from the distributed cache for each access and there will be significant penalty for performance. For clustering purpose only. --> <attribute name="UseLocalCache">false</attribute> <!-- Whether to use MOD_JK(2) for load balancing with sticky session combined with JvmRoute. If set to true, it will insert a JvmRouteFilter to intercept every request and replace the JvmRoute if it detects a failover. In addition, you will need to set the JvmRoute inside Tomcat, e.g., Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost" in server.xml. For clustering purpose only. --> <attribute name="UseJK">true</attribute> <attribute name="Domain">jboss.web</attribute> <!-- A mapping to the server security manager service which must be operation compatible with type org.jboss.security.plugins.JaasSecurityManagerServiceMBean. This is only needed if web applications are allowed to flush the security manager authentication cache when the web sessions invalidate. --> <depends optional-attribute-name="SecurityManagerService" proxy-type="attribute">jboss.security:service=JaasSecurityManager </depends> <!-- Configuration for HTTP Session Clustering using JBossCache--> <!--<depends optional-attribute-name="CacheName">jboss.cache:service=TreeCache</depends>--> <depends>jboss.cache:service=TomcatClusteringCache</depends> <depends>jboss:service=TransactionManager</depends> <!-- Only needed if the org.jboss.web.tomcat.tc5.jca.CachedConnectionValve is enabled in the tomcat server.xml file <depends>jboss.jca:service=CachedConnectionManager</depends> --> </mbean> </server>
-
3. Re: Http sticky session in jboss 3.2.7
marinac Feb 26, 2006 12:44 PM (in response to marinac)This is the worker:
worker.list=loadbalancer,status ps=/ # Define Node1 worker.node1.port=8009 worker.node1.host=cphzt21.rdsas.com worker.node1.type=ajp13 worker.node1.lbfactor=1 #worker.node1.local_worker=1 worker.node1.cachesize=10 #worker.node1.cachesize=1 # Define Node2 worker.node2.port=8009 worker.node2.host=cphzt22.rdsas.com worker.node2.type=ajp13 worker.node2.lbfactor=1 #worker.node2.local_worker=1 worker.node2.cachesize=10 #worker.node2.cachesize=1 # Load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=node1,node2 worker.loadbalancer.sticky_session=1 worker.loadbalancer.sticky_session_force=1 #worker.loadbalancer.local_worker_only=1 #worker.list=loadbalancer # Status worker for managing load balancer worker.status.type=status
-
4. Re: Http sticky session in jboss 3.2.7
marinac Feb 26, 2006 1:36 PM (in response to marinac)In jbossweb-tomcat50.sar/server.xml, on both servers:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">