6 Replies Latest reply on Jun 23, 2008 5:54 PM by prabhat.jha

    Portal-Cluster: REPL_ASYNC vs. REPL_SYNC

    ironman77

      Hi,

      as a follow up to this posting

      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136198

      we have discovered some strange effects when using the default setting of

      REPL_SYNC for the TreeCache within a clustered portal setup. These issues include


      • the logout bug (see the post above)
      • synchronisation issues for PortletPreferences if the instance preferences are modified via the Admin-Portlet


        Strangley, these issues could be fixed when using the REPL_ASYNC setting for the TreeCache. I am aware of the drawbacks of using async vs sync but the sync settings doens't work as expected.

        Has anybody else experienced the same issues?






        • 1. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
          prabhat.jha

          Yes, I am aware of some problems when using REPL_SYNC and we are still investigating it. Your logout issue I believe is fixed in the latest portal release which is 2.6.5.SP1. Can you verify that at your side?

          I have created a jira issue http://jira.jboss.com/jira/browse/JBPORTAL-2044 for your problem and let me see if I can reproduce it. Please do more testing of clustered setup and report if you find more issues. Many thanks for your feedback.

          • 2. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
            prabhat.jha

            Are you hitting two servers directly or through a load balancer?

            • 3. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
              ironman77

              Although the logout has been fixed in 2.6.5-sp1 (i can confirm that!) it's no viable option for us. As we were already in a production environment there are to many changes in my opinion (many services have been renamed for example) to use it.

              As a follow up to the portlet preferences problem:

              We currently working to a solution with a hardare loadbalancer, but with sticky sessions - no HTTP-Session replication and no SSO. Only the configuration is clustered with a shared db.

              I can reproduce the issues without the load balancer if i adress the cluster nodes direct. Example: Three nodes (node-1, node-2, node-3).

              Say i configure a (new!) portlet instance via the admin portlet on node-1 and add it to a (new) window on a existing page.

              Log in to node-2 or being already logged in on node-3 (it doesn't seem to matter) the content of the PortletPreferences for the new instance from the JBossRenderRequest are NOT populated right - the "fall back" (mostly - not every time) to the standard values from the portlet.xml. They are ALWAYS(!) correct in node-1 and on all nodes(!) within the admin-portlet.

              I have spent some time debugging the issue - it seems that the InstanceDefintion is not popluated correct from the TreeCache. The InstanceDefinition should contain a value like "local_51" but it contains a value like "./portletname-local" or something. I have given up at this point , we are now working with the ASYNC setting.

              Kind regards,
              Stephan



              • 4. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
                prabhat.jha

                Your problem seems to be tied to your use case and it will be very hard (resource issues) for me to dig into it. I suggest that you use our support services and they will be able to replicate and fix your issues more quickly.

                • 5. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
                  prabhat.jha

                  IronMan77/Stepahan,

                  Which portllet did you use to replicate problem with preferences? If you could let me know the exact way to reproduce it, that would be great.

                  • 6. Re: Portal-Cluster: REPL_ASYNC vs. REPL_SYNC
                    prabhat.jha

                    I tested with IdentityUserPortletInstance in a 2-node cluster as admin user. I enabled captcha support and change was reflected when I brought down the node that was active. Please let me know how I can reproduce otherwise I will mark the jira as unreproducible.