[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
Now, there is a continuation of my story. Here is what I want to achieve:
I want to run a cluster (say, hostnames node1 and node2) with apache2 + mod_jk
loadballancer (hostname apache) with failover and loadballancing capabilities
and SSO across multiple applications. There are two aplications, of which one
is used much more often than the other, here is the detailed description I
submitted to tomcat-dev:
anonymous wrote :
| Let's assume there are two applications /app1 and /app2, and there is a SSO
| setup on them both. Now, user logs into the /app1 (which requires
| authentication) and /app2 (which uses SSO Cookie, no authentication then),
| and later on makes use of only one of them (say: /app1) for quite a long
| time, so that this period outlives the session expiry date of the unused
| application (/app2). Provided that both applications establish their own
| sessions the one created in the scope of constantly used application
| (/app1) wouldn't expire, while the second one definitely would.
|
| Now the question: As both sessions are gathered into a higher-level SSO
| session, would it be against the specification if *all* standard sessions
| were aged (eg. by calling session.access()) on each request containing
| valid SSO cookie? I suggest that there should be a flag on the SSO Valve,
| that is org.apache.catalina.authenticator.SingleSignOn allowing users to
| specify the behaviour.
|
You can find the original discussion here:
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg74023.html
To achieve this I added a simple aging logic to the ClusteredSingleSignOn. The
logic behind this is to age (call session.access()) all of the sessions that
are federated under the incoming SSO, provided that the requested session ID is
among them. Here is how my invoke() method looks like now (I have stripped
comments for brevity):
| public void invoke(Request request, Response response, ValveContext context)
| throws IOException, ServletException {
| if (!(request instanceof HttpRequest)
| || !(response instanceof HttpResponse)) {
| context.invokeNext(request, response);
| return;
| }
| HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
| HttpServletResponse hres = (HttpServletResponse) response.getResponse();
| request.removeNote(Constants.REQ_SSOID_NOTE);
|
| if (debug = 1)
| log(Process request for ' + hreq.getRequestURI() + ');
| if (hreq.getUserPrincipal() != null) {
| if (debug = 1)
| log( Principal ' + hreq.getUserPrincipal().getName()
| + ' has already been authenticated);
| context.invokeNext(request, response);
| return;
| }
|
| if (debug = 1)
| log( Checking for SSO cookie);
| Cookie cookie = null;
| Cookie cookies[] = hreq.getCookies();
| if (cookies == null)
| cookies = new Cookie[0];
| for (int i = 0; i cookies.length; i++) {
| if (Constants.SINGLE_SIGN_ON_COOKIE.equals(cookies.getName())) {
| cookie = cookies;
| break;
| }
| }
| if (cookie == null) {
| if (debug = 1)
| log( SSO cookie is not present);
| context.invokeNext(request, response);
| return;
| }
|
| if (debug = 1)
| log( Checking for cached principal for + cookie.getValue());
| SingleSignOnEntry entry = getSingleSignOnEntry(cookie.getValue());
| if (entry != null) {
| Principal ssoPrinc = entry.getPrincipal();
| if (debug = 1) {
| log( Found cached principal '
| + (ssoPrinc == null ? NULL :
ssoPrinc.getName())
| + ' with auth type ' + entry.getAuthType() +
');
| }
| request.setNote(Constants.REQ_SSOID_NOTE, cookie.getValue());
| if (!getRequireReauthentication() ssoPrinc != null) {
| ((HttpRequest)
request).setAuthType(entry.getAuthType());
| ((HttpRequest) request).setUserPrincipal(ssoPrinc);
| }
|
| if (keepaliveSessions) {
|
| Session[] sessions = entry.findSessions();
| String reqSessId = hreq.getRequestedSessionId();
| if (debug = 90) {
| log(requested session id + reqSessId);
| }
|
| boolean amongFlag = false;
| if (reqSessId != null) {
| for (int i = 0; i sessions.length; i++) {
| Session session =
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
I checked what you wanted me to and confirm that the TreeCache is up and running. Here is what I get on the stdout (Sorry for the huge log) | === | . | JBoss Bootstrap Environment | . | JBOSS_HOME: D:\java\jboss-4.0.1sp1\bin\\.. | . | JAVA: c:\java\jdk1.5.0\bin\java | . | JAVA_OPTS: -Dprogram.name=run.bat -Dcom.sun.management.jmxremote -Xms32m -Xmx128m | . | CLASSPATH: c:\java\jdk1.5.0\lib\tools.jar;D:\java\jboss-4.0.1sp1\bin\\run.jar | . | CMD PARAMS: -c all1 -b node1 | . | === | . | 12:11:27,171 INFO [Server] Starting JBoss (MX MicroKernel)... | 12:11:27,233 INFO [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBoss_4_0_1_SP1 date=200502160314) | 12:11:27,296 INFO [Server] Home Dir: D:\java\jboss-4.0.1sp1 | 12:11:27,374 INFO [Server] Home URL: file:/D:/java/jboss-4.0.1sp1/ | 12:11:27,389 INFO [Server] Library URL: file:/D:/java/jboss-4.0.1sp1/lib/ | 12:11:27,405 INFO [Server] Patch URL: null | 12:11:27,421 INFO [Server] Server Name: all1 | 12:11:27,436 INFO [Server] Server Home Dir: D:\java\jboss-4.0.1sp1\server\all1 | 12:11:27,436 INFO [Server] Server Home URL: file:/D:/java/jboss-4.0.1sp1/server/all1/ | 12:11:27,468 INFO [Server] Server Data Dir: D:\java\jboss-4.0.1sp1\server\all1\data | 12:11:27,483 INFO [Server] Server Temp Dir: D:\java\jboss-4.0.1sp1\server\all1\tmp | 12:11:27,499 INFO [Server] Server Config URL: file:/D:/java/jboss-4.0.1sp1/server/all1/conf/ | 12:11:27,499 INFO [Server] Server Library URL: file:/D:/java/jboss-4.0.1sp1/server/all1/lib/ | 12:11:27,514 INFO [Server] Root Deployment Filename: jboss-service.xml | 12:11:27,530 INFO [Server] Starting General Purpose Architecture (GPA)... | 12:11:28,155 INFO [ServerInfo] Java version: 1.5.0_04,Sun Microsystems Inc. | 12:11:28,171 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_04-b05,Sun Microsystems Inc. | 12:11:28,186 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 | 12:11:28,936 INFO [Server] Core system initialized | 12:11:33,030 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:log4j.xml | 12:11:33,202 INFO [WebService] Using RMI server codebase: http://node1:8083/ | 12:11:33,499 INFO [NamingService] Started jndi bootstrap jnpPort=1099,rmiPort=1098, backlog=50, bindAddress=node1/10.0.0.1, Client SocketFactory=null, Server [EMAIL PROTECTED] | 12:11:43,529 INFO [DefaultPartition] Initializing | 12:11:43,701 INFO [STDOUT] | --- | GMS: address is node1:2403 (additional data: 13 bytes) | --- | 12:11:45,764 INFO [DefaultPartition] Number of cluster members: 1 | 12:11:45,779 INFO [DefaultPartition] Other members: 0 | 12:11:45,795 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta: 0) : [10.0.0.1:1099] | 12:11:45,811 INFO [DefaultPartition] Fetching state (will wait for 3 milliseconds): | 12:11:45,842 INFO [DefaultPartition] I am (10.0.0.1:1099) received membershipChanged event: | 12:11:45,858 INFO [DefaultPartition] Dead members: 0 ([]) | 12:11:45,873 INFO [DefaultPartition] New Members : 0 ([]) | 12:11:45,889 INFO [DefaultPartition] All Members : 1 ([10.0.0.1:1099]) | 12:11:46,154 INFO [HANamingService] Listening on node1/10.0.0.1:1100 | 12:11:46,170 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on /10.0.0.1:1102, group=230.0.0.4, HA-JNDI ad | dress=10.0.0.1:1100 | 12:11:49,873 INFO [MailService] Mail Service bound to java:/Mail | 12:11:50,514 INFO [BlockingServer] Remoting 'async' protocol clients will connect to: InvokerLocator [async://10.160.32.251:8085/?compression=-1tcp.nodelay=true] | 12:11:51,029 INFO [TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=64;loopback=false;mcast_addr=230.1.2.3;mcast_port=45577;mcast_recv_buf_size=8;mcast_send_buf_size=15;ucast_recv_buf_size=8;ucast_send_buf_size=15):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=2;min_interval=1):FD_SOCK:VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=true;up_thread=true) | 12:11:51,170 INFO [TreeCache] interceptor chain is: | class org.jboss.cache.interceptors.CallInterceptor |
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
I kept investigating the problem and found the difference betweeen the machine where Clustered SSO works for me and the one where it doesn't. Moreover, I found the root of described the problem! Apparently some time ago I wanted to be able to reach jboss JVM via sun's jconsole, therefore I modified the startup script run.bat, and appended -Dcom.sun.management.jmxremote system property. You can observe this in the provided log. The addition of this parameter rendered Clustered SSO unusable. The question is: why the heck this happens! The quicksimple resolution is the removal of -Dcom.sun.management.jmxremote. Again, is there any sensible reason why this affects ONLY Clustered SSO?? Now, finally, back to the drawing board... cheers, /dd View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887693#3887693 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887693 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - Re: ClusteredSingleSignOn - TreeCacheSSOClusterManager fails
Again, here are the datailed steps I took to get this odd behaviour surface. 1. Take the standard all configuration. It has all in store (session replication via TreeCache defined in tc5-cluster-service.xml) 2. Add the dependency on the jboss.cache:service=TomcatClusteringCache to the jbossweb-tomcat50.sar/META-INF/jboss-service.xml 3. Enable the ClusteredSingleSignOn valve in tomcat's server.xml That's all. I hereby confirm that jboss.cache:service=TomcatClusteringCache MBean is indeed registered, moreover standard sessions do get replicated across the members of the cluster (I first observed this behaviour when starting two instances of jboss on one machine binding them to two different IPs, but this also happens when I try to start jboss without specifying the IP address to bind). As for the questions you have asked - let me double check tomorrow at work where oddity happens (particularly Q2 as I seem to have answered Q1 already, and my response to Q3 does not seem to be necessary - no particular changes to the files you had requested). On second thought, I'll email the modifed files to you. BTW, this also happens to jboss 4.0.2. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887603#3887603 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887603 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Clustering/JBoss] - ClusteredSingleSignOn - TreeCacheSSOClusterManager fails to
I'am constantly getting this on both server startup as well as on each SSO replication event. 16:45:53,212 INFO [TreeCacheSSOClusterManager] Cannot find TreeCache using jboss.cache:service=TomcatClusteringCache -- | treeCacheName must be set to point to a running TreeCache before ClusteredSingleSignOn can handle requests TreeCache *is* however configured beforehand as the log entries state. This happens to me when using my customized (stripped down a bit) server configuration. Then I gave a spin to the all server and observed similar behaviour. The only changes in original all configuration files were: * enabling the org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn Valve in tomcat server.xml * fix the dependency of Tomcat service on the jboss.cache:service=TomcatClusteringCache in tomcat's jboss-service.xml There is a part of the log (greped by TreeCache, showing that the apropriate tree cache had already been started) 2005-07-28 16:53:22,027 DEBUG [org.jboss.system.ServiceCreator] About to create bean: jboss.cache:service=TomcatClusteringCache with code: org.jboss.cache.TreeCache | 2005-07-28 16:53:22,199 INFO [org.jboss.cache.TreeCache] setting cluster properties from xml to: UDP(ip_mcast=true;ip_ttl=64;loopback=false;mcast_addr=230.1.2.3;mcast_port=45577;mcast_recv_buf_size=8;mcast_send_buf_size=15;ucast_recv_buf_size=8;ucast_send_buf_size=15):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=2;min_interval=1):FD_SOCK:VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=true;up_thread=true) | 2005-07-28 16:53:22,215 DEBUG [org.jboss.cache.TreeCache] Creating jboss.cache:service=TomcatClusteringCache | 2005-07-28 16:53:22,215 DEBUG [org.jboss.cache.TreeCache] Created jboss.cache:service=TomcatClusteringCache | 2005-07-28 16:53:22,230 DEBUG [org.jboss.cache.TreeCache] Starting jboss.cache:service=TomcatClusteringCache | 2005-07-28 16:53:22,293 INFO [org.jboss.cache.TreeCache] interceptor chain is: | 2005-07-28 16:53:22,293 INFO [org.jboss.cache.TreeCache] cache mode is REPL_SYNC | 2005-07-28 16:53:24,387 INFO [org.jboss.cache.TreeCache] viewAccepted(): new members: [W20609:3701] | 2005-07-28 16:53:24,387 INFO [org.jboss.cache.TreeCache] new cache is null (maybe first member in cluster) | 2005-07-28 16:53:24,402 INFO [org.jboss.cache.TreeCache] state could not be retrieved (must be first member in group) | 2005-07-28 16:53:24,402 DEBUG [org.jboss.cache.TreeCache] Started jboss.cache:service=TomcatClusteringCache | 2005-07-28 16:53:26,496 INFO [org.jboss.web.tomcat.tc5.sso.TreeCacheSSOClusterManager] Cannot find TreeCache using jboss.cache:service=TomcatClusteringCache -- treeCacheName must be set to point to a running TreeCache before ClusteredSingleSignOn can handle requests Need I mention that the SSO data do not get replicated across the cluster while the plain http session data does? I'am running jboss 4.0.1sp1 on the latest Sun Java 1.5.0_04 on XP sp2. Now, there comes the weird part. The *very same* configuration when gzipped and moved over to another machine (yep, as you might have expected running jboss 4.0.1sp1 on the latest Sun Java 1.5.0_04 on XP sp2, too) runs like a charm? Has anybody else run into similar problem? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3887086#3887086 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887086 --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
