Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.2, 2.1.3, 2.2.0
    • Fix Version/s: 2.1.4, 2.2.0
    • Component/s: Other
    • Labels:
      None

      Description

      We developed a cluster synchronization feature that is able to synchronize the execution of an objects method cluster-wide. The approach is similar to the spring transaction proxy, so we are able to AOP-inject the cluster synchronization via spring configuration. The component is highly customizable. A new database table is used for synchonization, but any other data container (i.e. broadcast-distributed-hashmap) could be used.

      One main application for this functionality is the start of many jetspeed cluster nodes and synchronize the deployment of the PAs to the database. (Even with the VersionedApplicationManager we experienced DB constraints failures on startup with fresh database, preventing the some PAs from registration.)

      Patch follows (exists only for the 2.1.2-POSTRELEASE branch yet).

      1. JS2-893_patch.zip
        29 kB
        Joachim Müller

        Activity

        Hide
        hongkunan added a comment - - edited

        thanks your answer!

        I follow your step,but login is error.
        javax.security.auth.login.LoginException:The user null dose not exist

        my env:
        OS: windows xp
        jdk:1.5
        server:tomcat6(jetspeed self install)
        http: apache2.2
        database:oracle92

        jetspeed.properties

        1. Cache page manager override properties, (these override above legacy properties if set)
        2. database page manager cache size:
          org.apache.jetspeed.ehcache.pagemanager.maxelements=128
        3. database page manager cache element expiration in seconds, (infinite = 0):
          org.apache.jetspeed.ehcache.pagemanager.element.ttl=150
        4. PSML page manager file cache size:
          org.apache.jetspeed.ehcache.pagemanager.maxfiles=1000

        #-------------------------------------------------------------------------

        1. C A C H E
          #-------------------------------------------------------------------------
        2. cache configuration resource, ('ehcache.xml' or 'distributed-ehcache.xml' supported by default):
          org.apache.jetspeed.ehcache.config.resource=ehcache.xml
        3. distributed cache peer discovery multicast address:
          org.apache.jetspeed.ehcache.group.address=230.0.0.1
        4. distributed cache peer discovery multicast port:
          org.apache.jetspeed.ehcache.group.port=4446
        5. distributed cache peer discovery multicast TTL, (0=host, 1=subnet, ... see ehcache.xml):
          org.apache.jetspeed.ehcache.group.ttl=1
        6. distributed cache peer hostname, (set to listen on specific interface):
          org.apache.jetspeed.ehcache.hostname=localhost
        7. distributed cache peer port:
          org.apache.jetspeed.ehcache.port=40001
        Show
        hongkunan added a comment - - edited thanks your answer! I follow your step,but login is error. javax.security.auth.login.LoginException:The user null dose not exist my env: OS: windows xp jdk:1.5 server:tomcat6(jetspeed self install) http: apache2.2 database:oracle92 jetspeed.properties Cache page manager override properties, (these override above legacy properties if set) database page manager cache size: org.apache.jetspeed.ehcache.pagemanager.maxelements=128 database page manager cache element expiration in seconds, (infinite = 0): org.apache.jetspeed.ehcache.pagemanager.element.ttl=150 PSML page manager file cache size: org.apache.jetspeed.ehcache.pagemanager.maxfiles=1000 #------------------------------------------------------------------------- C A C H E #------------------------------------------------------------------------- cache configuration resource, ('ehcache.xml' or 'distributed-ehcache.xml' supported by default): org.apache.jetspeed.ehcache.config.resource=ehcache.xml distributed cache peer discovery multicast address: org.apache.jetspeed.ehcache.group.address=230.0.0.1 distributed cache peer discovery multicast port: org.apache.jetspeed.ehcache.group.port=4446 distributed cache peer discovery multicast TTL, (0=host, 1=subnet, ... see ehcache.xml): org.apache.jetspeed.ehcache.group.ttl=1 distributed cache peer hostname, (set to listen on specific interface): org.apache.jetspeed.ehcache.hostname=localhost distributed cache peer port: org.apache.jetspeed.ehcache.port=40001
        Hide
        hongkunan added a comment -

        where have jetspeed2.2 cluster detail's document??

        who can give me a document? thanks!

        my email: jones_ahk@yahoo.com.cn

        Show
        hongkunan added a comment - where have jetspeed2.2 cluster detail's document?? who can give me a document? thanks! my email: jones_ahk@yahoo.com.cn
        Hide
        Randy Watler added a comment -

        PAM implementations are now capable of successfully rolling back and retrying portlet application registrations in both the 2.2 trunk and 2.1.3-POST branch, (to be 2.1.4).

        Fixes included adding retry loop in startPortletApplication APIs and cleaning up prefs cache in the 2.1.3-POST branch. The 2.2 trunk has a new prefs/registry implementation that did not require any improvements based on the need to recover successfully from failed registrations.

        2.1.3 svn commit: 769669
        2.2 svn commit: 769670

        The new service proposed as a fix for these problems was not encorporated. A new JIRA issue should be created to donate the service into the 2.2 and/or 2.1.4 if that is still desired.

        Show
        Randy Watler added a comment - PAM implementations are now capable of successfully rolling back and retrying portlet application registrations in both the 2.2 trunk and 2.1.3-POST branch, (to be 2.1.4). Fixes included adding retry loop in startPortletApplication APIs and cleaning up prefs cache in the 2.1.3-POST branch. The 2.2 trunk has a new prefs/registry implementation that did not require any improvements based on the need to recover successfully from failed registrations. 2.1.3 svn commit: 769669 2.2 svn commit: 769670 The new service proposed as a fix for these problems was not encorporated. A new JIRA issue should be created to donate the service into the 2.2 and/or 2.1.4 if that is still desired.
        Hide
        Randy Watler added a comment -

        Unit tests in 2.1.3-POST and 2.2 versions committed.

        2.2: 768433
        2.1.3: 768434

        Reported prefs problems do not appear in 2.2, so these will not be addressed as part of this issue.

        An attempt will be made to fix the concurrent startPortletApplication issue without using the patch submitted above. The primary reason we are avoiding the patch above is to prevent cluster wide locking. Database transactions should be sufficiently robust to implement concurrent PAM access. We will reconsider this approach if we are not able to achieve this.

        Show
        Randy Watler added a comment - Unit tests in 2.1.3-POST and 2.2 versions committed. 2.2: 768433 2.1.3: 768434 Reported prefs problems do not appear in 2.2, so these will not be addressed as part of this issue. An attempt will be made to fix the concurrent startPortletApplication issue without using the patch submitted above. The primary reason we are avoiding the patch above is to prevent cluster wide locking. Database transactions should be sufficiently robust to implement concurrent PAM access. We will reconsider this approach if we are not able to achieve this.
        Hide
        Randy Watler added a comment -

        Investigation into this issue has confirmed that there are issues as reported using the VersionedPortletApplicationManager implementation on 2.1.3-POST. There are at least two issues that are evident at this point: concurrent access conflicts between multiple nodes in the cluster and problems writing preferences for a portlet application more than once during the lifetime of a single server.

        Show
        Randy Watler added a comment - Investigation into this issue has confirmed that there are issues as reported using the VersionedPortletApplicationManager implementation on 2.1.3-POST. There are at least two issues that are evident at this point: concurrent access conflicts between multiple nodes in the cluster and problems writing preferences for a portlet application more than once during the lifetime of a single server.
        Hide
        David Sean Taylor added a comment -

        I am changing the fix version to 2.2, since I cannot modify the database tables to a post release.
        Will review this before the 2.2 release and make a decision whether it should be included in the release as an optional or default feature.

        Show
        David Sean Taylor added a comment - I am changing the fix version to 2.2, since I cannot modify the database tables to a post release. Will review this before the 2.2 release and make a decision whether it should be included in the release as an optional or default feature.
        Hide
        Joachim Müller added a comment - - edited

        The patch should be modified in deployment.xml to use the VersionedPortletApplicationManager instead of the PortletApplicationManager (or at least set descriptorChangeMonitorInterval to 0). We experienced in some setups that the DescriptorChangeMonitor fires a startPA() before startPortletApplication was executed as it was blocked by the cluster synchronization.

        Unfortunately startPA() cannot be proxied because it is protected. What about making the method public so the cluster sync can hook in?

        Show
        Joachim Müller added a comment - - edited The patch should be modified in deployment.xml to use the VersionedPortletApplicationManager instead of the PortletApplicationManager (or at least set descriptorChangeMonitorInterval to 0). We experienced in some setups that the DescriptorChangeMonitor fires a startPA() before startPortletApplication was executed as it was blocked by the cluster synchronization. Unfortunately startPA() cannot be proxied because it is protected. What about making the method public so the cluster sync can hook in?
        Hide
        Joachim Müller added a comment -

        some more comments:

        A new table CLUSTER_RESOURCE is created to store the LOCK tokens. It also stores information about TTL and the client that obtained the lock.

        With the parameters in the new deployment.xml it is possible to influence different behaviours like: TTL, time to wait for retry obtaining a cluster wide lock and the max. number of retries before the proxy interrupts the method execution.

        Show
        Joachim Müller added a comment - some more comments: A new table CLUSTER_RESOURCE is created to store the LOCK tokens. It also stores information about TTL and the client that obtained the lock. With the parameters in the new deployment.xml it is possible to influence different behaviours like: TTL, time to wait for retry obtaining a cluster wide lock and the max. number of retries before the proxy interrupts the method execution.
        Hide
        Joachim Müller added a comment -

        patches for 2.1.2-POSTRELEASE, 2.1.3-POSTRELEASE, 2.2-dev

        Show
        Joachim Müller added a comment - patches for 2.1.2-POSTRELEASE, 2.1.3-POSTRELEASE, 2.2-dev

          People

          • Assignee:
            Randy Watler
            Reporter:
            Joachim Müller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development