3 Replies Latest reply on Nov 27, 2002 10:28 AM by jakefear

    Container Managed Security fail-over not support?

    gysgys

      Hi,

      After several days' fumbling I finally have my Apache_2.0.43+mod_jk2+JBoss-3.0.3_Tomcat-4.1.12+w2k talk to each other.I have two jboss-tomcat instances running on two machines and an Apache2 sitting in front acting as a load balancer.They work great in a clustering environment and thanks for all your hard work there.I'd like to share with anyone there who is interested in my configuration.

      The HttpSession replication works well in my test as my test app works as following:
      One jsp page is used to create a session and set some attributes.The other jsp page to getAttribute.
      And then I start the first jboss-tomcat server,from a browser I access the above pages through Apache2,no problem.After that I start the second jboss-tomcat server and shutdown the first one,and use the second jsp to access the session,It's there! wonderfull!

      So good so far,but when come to the protected page,I am not such lucky.I use the declarative security model to protected my web page.The login method is "form" and for test I use UserRolesLoginModule.The process is almost the same as above:
      I start the first server,through Apache2 I access the protected pages.The server prompts a form page asking for login input.I login and then I can access other protected pages in the same session.
      Then I start the second server,shutdown the first one.I refresh the browser,the server prompts for login again!!!Obvious no replication of the login credential.I know that the login credential is saved somewhere else.So my question is "is the CMS fail-over as I explained above supported?"Any tips are highly appreciated.

      Sorry for my English and the lengthy post.

      Best,

      Yingshou

        • 1. Re: Container Managed Security fail-over not support?
          jakefear

          I am struggling with the same issue. If I come up with anything I will let you know. See my posts for what I have tried. It appeared the ClusteredSession used a principal attribute which was transient. I changed to no avail. Please let me know if find a solution, and I will do the same.

          Jake

          • 2. Re: Container Managed Security fail-over not support?
            gysgys

            Jake,

            The best way maybe to dive into the source to find out the answer and figure out what we can do with it.Without this kind of clustering feature,I think jboss clustering will not be as useful as it seems to be.I know there are quite a lot starting projects that use the J2EE Declarative Security Model to implement their security requirement.

            However,before doing that I just want someone there who have done the clustering stuff give me a confirmation whether it's supported or not.

            If I can find a solution,I surely will be happy to share with you the knowhow.The problem is that for the time being I'am busy one other things.About 10 days later,I'll come back to this issue.

            Yingshou

            • 3. Re: Container Managed Security fail-over not support?
              jakefear

              I have been knocking my head on this constantly for two days now. I I setup with the configuration for tomcat/jboss/apachage directly out of the FAQ. I will happilly attach the file if it would be helpful, but they are essentally identical. FOr the clustering configuration I followed instructions in the clustering docs (adding the file jboss jbossha-httpsession.sar, adding the javagroups2.0.jar file to the default/lib directory and adding the cluster-service.xml file to the default/deploy directory). And for the mostpart clustering seems to work (after I have been asked to login twice :(. Any help will be much appreciated.

              If there are any particular files I couild provide to help someone trouble shoot please let me know)

              For now I have resorted to a simpler load balancing scenario with sticky sessions using the jvmRoute parameter. This approach scales well, but does not provide the transparent failover my customers desire.