JBoss Clustering / JAAS
wrfeldmann Jan 27, 2010 4:00 PMEveryone,
I have the following configuration and have been unable to have the logons work properly. Once properly logged in, I can terminate app2 on either server and it will bounce to the other server. It will even bounce during normal execution between the 2 servers. What am I missing?
Jboss - 4.0.5
Jboss cache - 1.4.0
app1 is using a custom written sso module and is configured to have it's own session cache that is shared with other servers running app1.
app2 is configured to have it's on session cache that is shared with other servers running app2.
both app1 and app2 have a shared credential cache.
our shared credential cache configuration file looks like and is the same for both applications on all servers in the deploy directory:
<?xml version="1.0" encoding="UTF-8" ?>
<server>
<classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration for the Credential Cache. -->
<!-- ==================================================================== -->
<mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=COTreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- Configure the TransactionManager -->
<!-- org.jboss.cache.DummyTransactionManagerLookup -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!--
Node locking scheme :
PESSIMISTIC (default)
OPTIMISTIC
-->
<attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
<!--
Node locking isolation level :
SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
(ignored if NodeLockingScheme is OPTIMISTIC)
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
INVALIDATION_ASYNC
INVALIDATION_SYNC
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!-- Whether each interceptor should have an mbean
registered to capture and display its statistics. <attribute name="UseInterceptorMbeans">true</attribute>
-->
<!--
Name of cluster. Needs to be the same for all clusters,
in order to find each other
-->
<attribute name="ClusterName">Credential-${jboss.partition.name:DefaultPartition}</attribute>
<attribute name="ClusterConfig">
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.10}" mcast_port="45568"
ip_ttl="${jgroups.mcast.ip_ttl:8}" ip_mcast="true"
mcast_recv_buf_size="2000000" mcast_send_buf_size="640000"
ucast_recv_buf_size="2000000" ucast_send_buf_size="640000"
enable_bundling="false"
loopback="false" />
<PING timeout="2000" num_initial_members="4" />
<MERGE2 min_interval="10000" max_interval="20000" />
<FD_SOCK />
<FD shun="true" timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="3000" num_msgs="3" />
<pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
max_xmit_size="8192" />
<UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10" />
<pbcast.STABLE desired_avg_gossip="20000" max_bytes="400000" />
<FRAG frag_size="8192" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER />
</config>
</attribute>
<!-- The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
<attribute name="InitialStateRetrievalTimeout">5000</attribute>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">10000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
</mbean>
</server>
the jboss-service.xml file in tc5-cluster-sar/META-INF directory for app1 is:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
<!-- -->
<!-- ===================================================================== -->
<server>
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<!-- Note we are using TreeCacheAop -->
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- We need the AspectDeployer to deploy our FIELD granularity aspects -->
<depends>jboss.aop:service=AspectDeployer</depends>
<!-- Name of cluster. Needs to be the same for all nodes in the
cluster, in order to find each other
-->
<attribute name="ClusterName">APP1-Session-${jboss.partition.name:Cluster}</attribute>
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
If you use REPL_SYNC and a UDP-based ClusterConfig
we recommend you comment out the FC (flow control)
protocol in the ClusterConfig section below.
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!--
Indicates whether to the cache should unmarshall objects replicated
from other cluster nodes, or store them internally as a byte[]
until a web app requests them. Must be "true" if session replication
granularity "FIELD" is used in any webapp, otherwise "false" is
recommended.
-->
<attribute name="UseRegionBasedMarshalling">false</attribute>
<!-- Whether or not the entire tree is inactive upon startup, only
responding to replication messages after activateRegion() is
called to activate one or more parts of the tree when a webapp is
deployed. Must have the same value as "UseRegionBasedMarshalling".
-->
<attribute name="InactiveOnStartup">false</attribute>
<!-- Make sure to specify BatchModeTransactionManager only! -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!-- Configures binary format of messages sent between cluster nodes.
Changing this allows a later version of JBoss Cache to interoperate
with an earlier version. You might, for example, change this
if you are integrating a 4.0.4 server into a cluster with
servers running an earlier AS version.
Possible values:
1.2.3 JBC 1.2.3 or earlier; bundled with AS 4.0.3.SP1 and earlier
1.2.4 JBC 1.2.4
1.2.4.SP1 JBC 1.2.4.SP1
1.2.4.SP2 JBC 1.2.4.SP2; bundled with AS 4.0.4
For version 1.3.0.GA and later, use the version name.
If left blank or commented out, JBoss Cache will use the default
for that release (e.g. 1.4.0 for releases in the 1.4.0 series.
The binary format of replication version 1.4.0 is much more efficient
than earlier releases, so there is a significant performance penalty
to trying to interoperate 1.4.0 with earlier releases vs. a pure
1.4.0 cluster.
-->
<attribute name="ReplicationVersion">1.4.0.GA</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<!--
The default UDP stack:
- If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
appropriate NIC IP address, e.g bind_addr="192.168.0.2".
- On Windows machines, because of the media sense feature being broken with multicast
(even after disabling media sense) set the UDP protocol's loopback attribute to true
- If your CacheMode is set to REPL_SYNC we recommend you comment
out the FC (flow control) protocol
-->
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.30}"
mcast_port="45577"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
ip_ttl="${jgroups.mcast.ip_ttl:2}"
enable_bundling="false"/>
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="100000" min_interval="20000"/>
<FD_SOCK />
<FD shun="true" timeout="20000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="50"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600" />
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
join_retry_timeout="2000" shun="true"/>
<!-- commented out based on recommendation above about using REPL_SYNC instead of REPL_ASYNC <FC max_credits="2000000" min_threshold="0.10"/> -->
<FRAG2 frag_size="60000" />
<pbcast.STATE_TRANSFER />
</config>
<!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
<!--
<config>
<TCP bind_addr="thishost" start_port="7810" loopback="true"
tcp_nodelay="false" down_thread="false" up_thread="false"/>
<TCPPING initial_hosts="thishost[7810],otherhost[7810]" port_range="3" timeout="3500"
num_initial_members="3" up_thread="false" down_thread="false"/>
<MERGE2 min_interval="5000" max_interval="10000"
up_thread="false" down_thread="false"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD shun="true" up_thread="false" down_thread="false"
timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
<pbcast.NAKACK down_thread="false" up_thread="false" gc_lag="100"
retransmit_timeout="3000"/>
<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true"
print_local_addr="true" down_thread="false" up_thread="false"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
</config>
-->
</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">20000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Buddy Replication config.
See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign
and the JBoss Cache docs for more on buddy replication.
By default, buddy replication is disabled.
Following are the configuration elements likely to be changed:
buddyReplicationEnabled true if you want buddy replication; false if data
should be replicated to all nodes in the cluster
numBuddies to how many backup nodes should each node replicate
its state
buddyPoolName allows logical subgrouping of nodes within the cluster;
if possible, buddies will be chosen from nodes in the
same buddy pool
Do not change the data gravitation related options. -->
<attribute name="BuddyReplicationConfig">
<config>
<buddyReplicationEnabled>false</buddyReplicationEnabled>
<buddyLocatorClass>org.jboss.cache.buddyreplication.NextMemberBuddyLocator</buddyLocatorClass>
<buddyLocatorProperties>
numBuddies = 1
ignoreColocatedBuddies = true
</buddyLocatorProperties>
<buddyPoolName>default</buddyPoolName>
<buddyCommunicationTimeout>2000</buddyCommunicationTimeout>
<autoDataGravitation>false</autoDataGravitation>
<dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind>
<dataGravitationSearchBackupTrees>true</dataGravitationSearchBackupTrees>
</config>
</attribute>
</mbean>
</server>
the jboss-service.xml file in tc5-cluster-sar/META-INF directory for app2 is:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
<!-- -->
<!-- ===================================================================== -->
<server>
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<!-- Note we are using TreeCacheAop -->
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- We need the AspectDeployer to deploy our FIELD granularity aspects -->
<depends>jboss.aop:service=AspectDeployer</depends>
<!-- Name of cluster. Needs to be the same for all nodes in the
cluster, in order to find each other
-->
<attribute name="ClusterName">APP2-Session-${jboss.partition.name:Cluster}</attribute>
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
If you use REPL_SYNC and a UDP-based ClusterConfig
we recommend you comment out the FC (flow control)
protocol in the ClusterConfig section below.
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!--
Indicates whether to the cache should unmarshall objects replicated
from other cluster nodes, or store them internally as a byte[]
until a web app requests them. Must be "true" if session replication
granularity "FIELD" is used in any webapp, otherwise "false" is
recommended.
-->
<attribute name="UseRegionBasedMarshalling">false</attribute>
<!-- Whether or not the entire tree is inactive upon startup, only
responding to replication messages after activateRegion() is
called to activate one or more parts of the tree when a webapp is
deployed. Must have the same value as "UseRegionBasedMarshalling".
-->
<attribute name="InactiveOnStartup">false</attribute>
<!-- Make sure to specify BatchModeTransactionManager only! -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!-- Configures binary format of messages sent between cluster nodes.
Changing this allows a later version of JBoss Cache to interoperate
with an earlier version. You might, for example, change this
if you are integrating a 4.0.4 server into a cluster with
servers running an earlier AS version.
Possible values:
1.2.3 JBC 1.2.3 or earlier; bundled with AS 4.0.3.SP1 and earlier
1.2.4 JBC 1.2.4
1.2.4.SP1 JBC 1.2.4.SP1
1.2.4.SP2 JBC 1.2.4.SP2; bundled with AS 4.0.4
For version 1.3.0.GA and later, use the version name.
If left blank or commented out, JBoss Cache will use the default
for that release (e.g. 1.4.0 for releases in the 1.4.0 series.
The binary format of replication version 1.4.0 is much more efficient
than earlier releases, so there is a significant performance penalty
to trying to interoperate 1.4.0 with earlier releases vs. a pure
1.4.0 cluster.
-->
<attribute name="ReplicationVersion">1.4.0.GA</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<!--
The default UDP stack:
- If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
appropriate NIC IP address, e.g bind_addr="192.168.0.2".
- On Windows machines, because of the media sense feature being broken with multicast
(even after disabling media sense) set the UDP protocol's loopback attribute to true
- If your CacheMode is set to REPL_SYNC we recommend you comment
out the FC (flow control) protocol
-->
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.20}"
mcast_port="45577"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
ip_ttl="${jgroups.mcast.ip_ttl:2}"
enable_bundling="false"/>
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="100000" min_interval="20000"/>
<FD_SOCK />
<FD shun="true" timeout="20000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="50"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600" />
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
join_retry_timeout="2000" shun="true"/>
<!-- commented out based on recommendation above about using REPL_SYNC instead of REPL_ASYNC <FC max_credits="2000000" min_threshold="0.10"/> -->
<FRAG2 frag_size="60000" />
<pbcast.STATE_TRANSFER />
</config>
<!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
<!--
<config>
<TCP bind_addr="thishost" start_port="7810" loopback="true"
tcp_nodelay="false" down_thread="false" up_thread="false"/>
<TCPPING initial_hosts="thishost[7810],otherhost[7810]" port_range="3" timeout="3500"
num_initial_members="3" up_thread="false" down_thread="false"/>
<MERGE2 min_interval="5000" max_interval="10000"
up_thread="false" down_thread="false"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD shun="true" up_thread="false" down_thread="false"
timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
<pbcast.NAKACK down_thread="false" up_thread="false" gc_lag="100"
retransmit_timeout="3000"/>
<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true"
print_local_addr="true" down_thread="false" up_thread="false"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
</config>
-->
</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">20000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Buddy Replication config.
See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign
and the JBoss Cache docs for more on buddy replication.
By default, buddy replication is disabled.
Following are the configuration elements likely to be changed:
buddyReplicationEnabled true if you want buddy replication; false if data
should be replicated to all nodes in the cluster
numBuddies to how many backup nodes should each node replicate
its state
buddyPoolName allows logical subgrouping of nodes within the cluster;
if possible, buddies will be chosen from nodes in the
same buddy pool
Do not change the data gravitation related options. -->
<attribute name="BuddyReplicationConfig">
<config>
<buddyReplicationEnabled>false</buddyReplicationEnabled>
<buddyLocatorClass>org.jboss.cache.buddyreplication.NextMemberBuddyLocator</buddyLocatorClass>
<buddyLocatorProperties>
numBuddies = 1
ignoreColocatedBuddies = true
</buddyLocatorProperties>
<buddyPoolName>default</buddyPoolName>
<buddyCommunicationTimeout>2000</buddyCommunicationTimeout>
<autoDataGravitation>false</autoDataGravitation>
<dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind>
<dataGravitationSearchBackupTrees>true</dataGravitationSearchBackupTrees>
</config>
</attribute>
</mbean>
</server>
the server.xml files for both apps contains the following valve:
<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" cacheConfig="Session-${jboss.partition.name:Cluster}"/>
We are behind physical load balancers performing round robin load balancing.
The sequence of events is as follow:
User opens browers and goes to url for app1.
app1 displays the login page and the user hits the submit button after entering a valid user id and password
app1 validates the user id and password
app1 logs into app2
app2 validates the user id and password
app2 returns successful login to app1
app1 returns a redirect (302) with the url of app2 to the browser
the browser then connects to app2.
if the browser hits app2 on the same server that app1 used for the login, the user is successfuly logged into app2 and shown the home page for app2. the user can then move around app2 without any knowledge of what server they are on and app2 can be stopped on either server and the user does not encounter any dropped connections.
if the browser hits app2 on a different server than app1 used for the login, the user is returned back to the app1 login page.
am I missing something in the configuration files?
yes, this is older release of jboss, but we are unable to upgrade the to a newer version at this time.
Thanks In Advance,
Rick Feldmann
work@rf-consulting.com
I have the following configuration and have been unable to have the logons work properly. Once properly logged in, I can terminate app2 on either server and it will bounce to the other server. It will even bounce during normal execution between the 2 servers. What am I missing?
Jboss - 4.0.5
Jboss cache - 1.4.0
app1 is using a custom written sso module and is configured to have it's own session cache that is shared with other servers running app1.
app2 is configured to have it's on session cache that is shared with other servers running app2.
both app1 and app2 have a shared credential cache.
our shared credential cache configuration file looks like and is the same for both applications on all servers in the deploy directory:
<?xml version="1.0" encoding="UTF-8" ?>
<server>
<classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration for the Credential Cache. -->
<!-- ==================================================================== -->
<mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=COTreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- Configure the TransactionManager -->
<!-- org.jboss.cache.DummyTransactionManagerLookup -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!--
Node locking scheme :
PESSIMISTIC (default)
OPTIMISTIC
-->
<attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
<!--
Node locking isolation level :
SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
(ignored if NodeLockingScheme is OPTIMISTIC)
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
INVALIDATION_ASYNC
INVALIDATION_SYNC
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!-- Whether each interceptor should have an mbean
registered to capture and display its statistics. <attribute name="UseInterceptorMbeans">true</attribute>
-->
<!--
Name of cluster. Needs to be the same for all clusters,
in order to find each other
-->
<attribute name="ClusterName">Credential-${jboss.partition.name:DefaultPartition}</attribute>
<attribute name="ClusterConfig">
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.10}" mcast_port="45568"
ip_ttl="${jgroups.mcast.ip_ttl:8}" ip_mcast="true"
mcast_recv_buf_size="2000000" mcast_send_buf_size="640000"
ucast_recv_buf_size="2000000" ucast_send_buf_size="640000"
enable_bundling="false"
loopback="false" />
<PING timeout="2000" num_initial_members="4" />
<MERGE2 min_interval="10000" max_interval="20000" />
<FD_SOCK />
<FD shun="true" timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="3000" num_msgs="3" />
<pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
max_xmit_size="8192" />
<UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10" />
<pbcast.STABLE desired_avg_gossip="20000" max_bytes="400000" />
<FRAG frag_size="8192" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER />
</config>
</attribute>
<!-- The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
<attribute name="InitialStateRetrievalTimeout">5000</attribute>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">10000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
</mbean>
</server>
the jboss-service.xml file in tc5-cluster-sar/META-INF directory for app1 is:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
<!-- -->
<!-- ===================================================================== -->
<server>
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<!-- Note we are using TreeCacheAop -->
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- We need the AspectDeployer to deploy our FIELD granularity aspects -->
<depends>jboss.aop:service=AspectDeployer</depends>
<!-- Name of cluster. Needs to be the same for all nodes in the
cluster, in order to find each other
-->
<attribute name="ClusterName">APP1-Session-${jboss.partition.name:Cluster}</attribute>
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
If you use REPL_SYNC and a UDP-based ClusterConfig
we recommend you comment out the FC (flow control)
protocol in the ClusterConfig section below.
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!--
Indicates whether to the cache should unmarshall objects replicated
from other cluster nodes, or store them internally as a byte[]
until a web app requests them. Must be "true" if session replication
granularity "FIELD" is used in any webapp, otherwise "false" is
recommended.
-->
<attribute name="UseRegionBasedMarshalling">false</attribute>
<!-- Whether or not the entire tree is inactive upon startup, only
responding to replication messages after activateRegion() is
called to activate one or more parts of the tree when a webapp is
deployed. Must have the same value as "UseRegionBasedMarshalling".
-->
<attribute name="InactiveOnStartup">false</attribute>
<!-- Make sure to specify BatchModeTransactionManager only! -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!-- Configures binary format of messages sent between cluster nodes.
Changing this allows a later version of JBoss Cache to interoperate
with an earlier version. You might, for example, change this
if you are integrating a 4.0.4 server into a cluster with
servers running an earlier AS version.
Possible values:
1.2.3 JBC 1.2.3 or earlier; bundled with AS 4.0.3.SP1 and earlier
1.2.4 JBC 1.2.4
1.2.4.SP1 JBC 1.2.4.SP1
1.2.4.SP2 JBC 1.2.4.SP2; bundled with AS 4.0.4
For version 1.3.0.GA and later, use the version name.
If left blank or commented out, JBoss Cache will use the default
for that release (e.g. 1.4.0 for releases in the 1.4.0 series.
The binary format of replication version 1.4.0 is much more efficient
than earlier releases, so there is a significant performance penalty
to trying to interoperate 1.4.0 with earlier releases vs. a pure
1.4.0 cluster.
-->
<attribute name="ReplicationVersion">1.4.0.GA</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<!--
The default UDP stack:
- If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
appropriate NIC IP address, e.g bind_addr="192.168.0.2".
- On Windows machines, because of the media sense feature being broken with multicast
(even after disabling media sense) set the UDP protocol's loopback attribute to true
- If your CacheMode is set to REPL_SYNC we recommend you comment
out the FC (flow control) protocol
-->
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.30}"
mcast_port="45577"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
ip_ttl="${jgroups.mcast.ip_ttl:2}"
enable_bundling="false"/>
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="100000" min_interval="20000"/>
<FD_SOCK />
<FD shun="true" timeout="20000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="50"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600" />
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
join_retry_timeout="2000" shun="true"/>
<!-- commented out based on recommendation above about using REPL_SYNC instead of REPL_ASYNC <FC max_credits="2000000" min_threshold="0.10"/> -->
<FRAG2 frag_size="60000" />
<pbcast.STATE_TRANSFER />
</config>
<!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
<!--
<config>
<TCP bind_addr="thishost" start_port="7810" loopback="true"
tcp_nodelay="false" down_thread="false" up_thread="false"/>
<TCPPING initial_hosts="thishost[7810],otherhost[7810]" port_range="3" timeout="3500"
num_initial_members="3" up_thread="false" down_thread="false"/>
<MERGE2 min_interval="5000" max_interval="10000"
up_thread="false" down_thread="false"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD shun="true" up_thread="false" down_thread="false"
timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
<pbcast.NAKACK down_thread="false" up_thread="false" gc_lag="100"
retransmit_timeout="3000"/>
<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true"
print_local_addr="true" down_thread="false" up_thread="false"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
</config>
-->
</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">20000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Buddy Replication config.
See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign
and the JBoss Cache docs for more on buddy replication.
By default, buddy replication is disabled.
Following are the configuration elements likely to be changed:
buddyReplicationEnabled true if you want buddy replication; false if data
should be replicated to all nodes in the cluster
numBuddies to how many backup nodes should each node replicate
its state
buddyPoolName allows logical subgrouping of nodes within the cluster;
if possible, buddies will be chosen from nodes in the
same buddy pool
Do not change the data gravitation related options. -->
<attribute name="BuddyReplicationConfig">
<config>
<buddyReplicationEnabled>false</buddyReplicationEnabled>
<buddyLocatorClass>org.jboss.cache.buddyreplication.NextMemberBuddyLocator</buddyLocatorClass>
<buddyLocatorProperties>
numBuddies = 1
ignoreColocatedBuddies = true
</buddyLocatorProperties>
<buddyPoolName>default</buddyPoolName>
<buddyCommunicationTimeout>2000</buddyCommunicationTimeout>
<autoDataGravitation>false</autoDataGravitation>
<dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind>
<dataGravitationSearchBackupTrees>true</dataGravitationSearchBackupTrees>
</config>
</attribute>
</mbean>
</server>
the jboss-service.xml file in tc5-cluster-sar/META-INF directory for app2 is:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
<!-- -->
<!-- ===================================================================== -->
<server>
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<!-- Note we are using TreeCacheAop -->
<mbean code="org.jboss.cache.aop.TreeCacheAop"
name="jboss.cache:service=TomcatClusteringCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!-- We need the AspectDeployer to deploy our FIELD granularity aspects -->
<depends>jboss.aop:service=AspectDeployer</depends>
<!-- Name of cluster. Needs to be the same for all nodes in the
cluster, in order to find each other
-->
<attribute name="ClusterName">APP2-Session-${jboss.partition.name:Cluster}</attribute>
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
If you use REPL_SYNC and a UDP-based ClusterConfig
we recommend you comment out the FC (flow control)
protocol in the ClusterConfig section below.
-->
<attribute name="CacheMode">REPL_SYNC</attribute>
<!--
Indicates whether to the cache should unmarshall objects replicated
from other cluster nodes, or store them internally as a byte[]
until a web app requests them. Must be "true" if session replication
granularity "FIELD" is used in any webapp, otherwise "false" is
recommended.
-->
<attribute name="UseRegionBasedMarshalling">false</attribute>
<!-- Whether or not the entire tree is inactive upon startup, only
responding to replication messages after activateRegion() is
called to activate one or more parts of the tree when a webapp is
deployed. Must have the same value as "UseRegionBasedMarshalling".
-->
<attribute name="InactiveOnStartup">false</attribute>
<!-- Make sure to specify BatchModeTransactionManager only! -->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.BatchModeTransactionManagerLookup</attribute>
<!-- Configures binary format of messages sent between cluster nodes.
Changing this allows a later version of JBoss Cache to interoperate
with an earlier version. You might, for example, change this
if you are integrating a 4.0.4 server into a cluster with
servers running an earlier AS version.
Possible values:
1.2.3 JBC 1.2.3 or earlier; bundled with AS 4.0.3.SP1 and earlier
1.2.4 JBC 1.2.4
1.2.4.SP1 JBC 1.2.4.SP1
1.2.4.SP2 JBC 1.2.4.SP2; bundled with AS 4.0.4
For version 1.3.0.GA and later, use the version name.
If left blank or commented out, JBoss Cache will use the default
for that release (e.g. 1.4.0 for releases in the 1.4.0 series.
The binary format of replication version 1.4.0 is much more efficient
than earlier releases, so there is a significant performance penalty
to trying to interoperate 1.4.0 with earlier releases vs. a pure
1.4.0 cluster.
-->
<attribute name="ReplicationVersion">1.4.0.GA</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<!--
The default UDP stack:
- If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
appropriate NIC IP address, e.g bind_addr="192.168.0.2".
- On Windows machines, because of the media sense feature being broken with multicast
(even after disabling media sense) set the UDP protocol's loopback attribute to true
- If your CacheMode is set to REPL_SYNC we recommend you comment
out the FC (flow control) protocol
-->
<config>
<UDP mcast_addr="${jboss.partition.udpGroup:224.0.0.20}"
mcast_port="45577"
ucast_recv_buf_size="20000000"
ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000"
mcast_send_buf_size="640000"
loopback="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
ip_ttl="${jgroups.mcast.ip_ttl:2}"
enable_bundling="false"/>
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="100000" min_interval="20000"/>
<FD_SOCK />
<FD shun="true" timeout="20000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="50"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200,2400,3600" />
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
join_retry_timeout="2000" shun="true"/>
<!-- commented out based on recommendation above about using REPL_SYNC instead of REPL_ASYNC <FC max_credits="2000000" min_threshold="0.10"/> -->
<FRAG2 frag_size="60000" />
<pbcast.STATE_TRANSFER />
</config>
<!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
<!--
<config>
<TCP bind_addr="thishost" start_port="7810" loopback="true"
tcp_nodelay="false" down_thread="false" up_thread="false"/>
<TCPPING initial_hosts="thishost[7810],otherhost[7810]" port_range="3" timeout="3500"
num_initial_members="3" up_thread="false" down_thread="false"/>
<MERGE2 min_interval="5000" max_interval="10000"
up_thread="false" down_thread="false"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD shun="true" up_thread="false" down_thread="false"
timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
<pbcast.NAKACK down_thread="false" up_thread="false" gc_lag="100"
retransmit_timeout="3000"/>
<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true"
print_local_addr="true" down_thread="false" up_thread="false"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
</config>
-->
</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">20000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">15000</attribute>
<!-- Buddy Replication config.
See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign
and the JBoss Cache docs for more on buddy replication.
By default, buddy replication is disabled.
Following are the configuration elements likely to be changed:
buddyReplicationEnabled true if you want buddy replication; false if data
should be replicated to all nodes in the cluster
numBuddies to how many backup nodes should each node replicate
its state
buddyPoolName allows logical subgrouping of nodes within the cluster;
if possible, buddies will be chosen from nodes in the
same buddy pool
Do not change the data gravitation related options. -->
<attribute name="BuddyReplicationConfig">
<config>
<buddyReplicationEnabled>false</buddyReplicationEnabled>
<buddyLocatorClass>org.jboss.cache.buddyreplication.NextMemberBuddyLocator</buddyLocatorClass>
<buddyLocatorProperties>
numBuddies = 1
ignoreColocatedBuddies = true
</buddyLocatorProperties>
<buddyPoolName>default</buddyPoolName>
<buddyCommunicationTimeout>2000</buddyCommunicationTimeout>
<autoDataGravitation>false</autoDataGravitation>
<dataGravitationRemoveOnFind>true</dataGravitationRemoveOnFind>
<dataGravitationSearchBackupTrees>true</dataGravitationSearchBackupTrees>
</config>
</attribute>
</mbean>
</server>
the server.xml files for both apps contains the following valve:
<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" cacheConfig="Session-${jboss.partition.name:Cluster}"/>
We are behind physical load balancers performing round robin load balancing.
The sequence of events is as follow:
User opens browers and goes to url for app1.
app1 displays the login page and the user hits the submit button after entering a valid user id and password
app1 validates the user id and password
app1 logs into app2
app2 validates the user id and password
app2 returns successful login to app1
app1 returns a redirect (302) with the url of app2 to the browser
the browser then connects to app2.
if the browser hits app2 on the same server that app1 used for the login, the user is successfuly logged into app2 and shown the home page for app2. the user can then move around app2 without any knowledge of what server they are on and app2 can be stopped on either server and the user does not encounter any dropped connections.
if the browser hits app2 on a different server than app1 used for the login, the user is returned back to the app1 login page.
am I missing something in the configuration files?
yes, this is older release of jboss, but we are unable to upgrade the to a newer version at this time.
Thanks In Advance,
Rick Feldmann
work@rf-consulting.com