Installation of CF03 on Portal 8.0 may fail with exception

When trying to install CF03 on Portal 8.0, Installation fails with below error:

opt/IBM/Rendering/PortalServer/installer/wp.config/config/includes/wp_cluster_cfg.xml:1436: Detected single app deployment time greater than 5 minutes.

Check the \wp_profile\ConfigEngine\log\ConfigTrace.log log file for the following error:-
/opt/IBM/Rendering/PortalServer/installer/wp.config/config/includes/wp_cluster_cfg.xml:1436: Detected single app deployment time greater than 5 minutes at  com.ibm.wplc.deploy.tasks.impl.ClusterWaitForSyncToCompleteImpl.execute(ClusterWaitForSyncToCompleteImpl.java:289) at  com.ibm.wplc.deploy.tasks.AbstractBaseAdminTask.executeBean(AbstractBaseAdminTask.java:541) at com.ibm.wplc.deploy.tasks.AbstractBaseAdminTask.executeTask(AbstractBaseAdminTask.java:525)  at com.ibm.wplc.deploy.tasks.AbstractBaseWsAdminWrapperTask.executeTask(Abs
tractBaseWsAdminWrapperTask.java:376)

In addition to that you will see error like below:
[wplc-wait-for-sync-to-complete] Distribution of AJAX Proxy Configuration not complete.
[wplc-wait-for-sync-to-complete] Distribution of Dojo_Resources not complete.

Workaround 1:

1. Try to increase maxAppTimeToWait="5" to 15 min. in wp_cluster_cfg.xml and run the installation again.
If doesn't work and you notice that wp_cluster_cfg.xml parameter revert back to lower value, then try the workaround below:

Workaround 2:

1. Edit the PortalServer/wps.properties file and remove the lines for:
ProfileName
ProfileDirectory

Do not just comment them out; remove them completely.

2. Install CF03. It should go through successfully this time. It will NOT update the profile so it should skip the failing script.
3. Make the same timeout changes to wp_cluster_cfg.xml again.
4. Add ProfileName and ProfileDirectory back to wps.properties.
5. Execute this ConfigEngine script to update the profile:
./ConfigEngine.sh CONFIG-WP-PTF-CF -DWasPassword= -DPortalAdminPwd=

If doesn't work, continue to next step.

Workaround 3:

1 Edit the Installation Manager configuration file, found at /opt/IBM/InstallationManager/eclipse/configuration/config.ini
2. Add the following line to this file: WP_UPDATE_SKIP_CONFIG=true
3. Save the file and run the portal installation again. You will need to run ./ConfigEngine.sh CONFIG-WP-PTF-CF -DWasPassword= -DPortalAdminPwd= to finish update.

Technote reference : http://www-01.ibm.com/support/docview.wss?uid=swg21622946

EJPSG0002E: Requested Member does not exist

You receive the following error message in the WebSphere Portal log: EJPSG0002E: Requested Member does not exist. uid=wpsadmin,o=defaultWIMFileBasedRealm/nullcauses initialization failures for portal server startup.

SystemOut.log says :

PortalCollect E com.ibm.hrl.portlets.WsPse.PortalCollectionsService PortalCollectionsService EJPJO0119E: Failed to initialize portal collections services.

java.lang.NoClassDefFoundError: com.ibm.wps.ac.impl.AccessControlDataManagement (initialization failure)
...
Caused by: java.lang.RuntimeException: Exception while loading dynamically re-ordered service class com.ibm.wps.ac.impl.AccessControlDataManagementService
...
Caused by: com.ibm.wps.ac.DomainAdministratorNotFoundException: EJPSB0107E: Exception occurred while retrieving the identity of the domain admin user/admingroup uid=wpsadmin,o=defaultWIMFileBasedRealm.
...
Caused by: com.ibm.portal.puma.MemberNotFoundException: EJPSG0002E: Requested Member does not exist.uid=wpsadmin,o=defaultWIMFileBasedRealm
...
Caused by: com.ibm.wps.um.exceptions.impl.MemberNotFoundExceptionImpl: com.ibm.portal.puma.MemberNotFoundException: EJPSG0002E: Requested Member does not exist.uid=wpsadmin,o=defaultWIMFileBasedRealm/null
...
Caused by: com.ibm.portal.puma.MemberNotFoundException: EJPSG0002E: Requested Member does not exist.uid=wpsadmin,o=defaultWIMFileBasedRealm/null
...

Accessing the Portal from a browser returns the following error:

404: Initialization of one or more services failed

Environment

Any Portal 6.1, 7.0 or 8.0 environment

Resolving the problem

Change the administrative user and group by running the ConfigEngine task wp-change-portal-admin-user. Specify an administrative user and group that exist in the repository.

Only if the ConfigEngine task fails and you need a manual work-around that enables WebSphere Portal to start:

Update all AdminUser and AdminGroup properties for the Access Control Data Management Service with the appropriate administrative user and group from the LDAP. 

Technote : 

http://www-01.ibm.com/support/docview.wss?uid=swg21366141

Caching Issue in WebSphere Portal version 6.1, 7.0 and 8.0

Currently Committed database setting - Applies to DB2 v9.7 or higher and WebSphere Portal version 6.1 and 7.0

 

DB2 V9.7 introduced a new default behaviour for isolation level cursor stability (CS) (see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0053556.html).
In WebSphere Portal this has implications for the cache invalidation strategy related to transactions. The new DB2 default behaviour for isolation level cursor stability (CS) is to NOT block code that wants to read data which is still being worked on in an uncommitted transaction in another thread (DB2 returns the result, as if the other transaction would not exist). But WebSphere Portal version 6.1 and 7.0 cache invalidation and refill strategies rely on the blocking at database level. With the new 'currently committed' default setting, stale data in Portal caches can occur.

Starting with Portal version 8.0 the setting of CUR_COMMIT to ENABLED is supported.

Besides the fact that CUR_COMMIT must be set to DISABLED for WebSphere Portal version 6.1 and 7.0, WebSphere Portal development does not expect a performance degradation when changing the value of CUR_COMMIT from ENABLED to DISABLED. For some scenarios with long database transactions, it could be that response times increase due to additional waits for updated data.

The setting of CUR_COMMIT is applied at database level. Therefore it is required to set CUR_COMMIT to DISABLED for the Portal database(s), containing the Portal database domains release, community, customization, jcr, feedback, and likeminds.

Disabling CUR_COMMIT in DB2 Version 9.7:

Ask your DB2 administrator to ensure that CUR_COMMIT is disabled by carrying out the following steps (for each of the Portal databases):

1. Connect to the runtime database:
   $ db2 connect to
   where represents the name of the database.
   
2. List the CUR_COMMIT parameter:
   $ db2 get db cfg show detail | grep CUR_COMMIT
   The output should look like this:
   Currently Committed (CUR_COMMIT) = DISABLED DISABLED
   
3. If the values are anything other than two times DISABLED (one for the current setting used, the other for the delayed setting specified in the configuration), change the value to DISABLED:
   $ db2 update db cfg using CUR_COMMIT DISABLED
   
4. Close the database connection:
   $ db2 connect reset
   
5. Check that no other application is connected to the database,to make the change effective (This e.g. requires to stop the Websphere Portal Server that uses the database). List the connected applications like this:
   $ db2 list applications for db
   where represents the name of the database.
   The output should look like this:
   SQL1611W No data was returned by Database System Monitor.
   
6. Ensure that the settings are correct by repeating the steps 1. and 2.

Full technote and source : http://www-01.ibm.com/support/docview.wss?uid=swg27037929&myns=swgws&mynp=OCSSHRKX&mync=E#!