Webserver Plugin configuration

How should I configure my web server plug-in for the best results ?

Cause

Some users are confused about how the ServerIOTimeout setting affects how the WebSphere web server plug-in handles failed requests. This document is intended to clarify this confusion.
There are competing factors that should be considered when determining the appropriate WebSphere web server plug-in settings for your environment. There is no single configuration that is correct for all environments. Please consider the following facts when selecting the best values for your environment.
- Connections consume resources on both the machine where the plug-in is installed and the machine where the application server is installed.
- Connections that do not terminate do not free these resources and can exhaust the resource pool.
- Time-out values set too low cause the client to experience unnecessary failures and increase the traffic load if the request is retried.
- Heavy traffic and intermediate issues can cause unexpected delays in responses.
- When an application response is not received within the ServerIOTimeout specification, you can decide whether to continue to send requests to that server. If you continue to send requests to that server, you risk additional time-outs and failures if there is a problem on the machine. If you decide to halt requests to that server, you decrease your sites capacity.
- Requests that contain a message body and typically can change the application state, such as a POST request, should not be retried unless the application is designed to accept multiple instances of the same request.
- Requests, typically GET and HEAD requests, that do not contain a message body are automatically retried by the plug-in when failures occur and this functionality cannot be disabled. If you configure the plug-in to stop using a server if time out issues occur, you must adjust other settings to ensure a single request never disables your entire site.

Answer

The WebSphere web server plug-in has several settings that should be examined when deciding how to best meet the needs of your clients.
The PostBufferSize property controls whether a request containing data, such as a POST request, will be retried to another server when failures and time-outs occur. By default, this property is set to 64K, which is the maximum content that can be buffered. If a request larger than this setting arrives, it will not be retried. Increasing the PostBufferSize property will consume more memory. As an alternative, you can disable the retry functionality of requests with content by setting the PostBufferSize property equal to 0, or you can set an unlimited buffer size by setting the PostBufferSize property to -1.
Requests that do not contain a body, such as GET requests, are automatically retried to another server whenever a failure or time-out occurs. This behavior cannot be disabled.

If a non-affinity request is retried, the plug-in will attempt to handle the request on each available server until a good response is received or each server has been tried. If an affinity request is retried and there is a positive ServerIOTimeout, affinity requests will be retried to the affinity appserver only. If there is a negative ServerIOTimeout, then the affinity server will be marked down and retries will be made to the remaining available servers.

The ServerIOTimeout property is designed to allow requests to time-out instead of waiting indefinitely for a response from the server. In Versions 6.1 and earlier, the ServerIOTimeout property defaults to 0, which indicates that there is no time limit for requests. This value is not recommended because if the a server never responds, the resources involved in this request might never be freed and eventually the resource pool is exhausted. In some cases, the operating system or adapter resources might break the connection because of inactivity but this is not behavior that should be relied on. You will need to determine the appropriate behavior for your environment if you plan to set the ServerIOTimeout property to 0.
If the ServerIOTimeout property is set to 0, do not expect requests to be retried. A request is not retried until the previous connection is broken and, as explained previously, the connection might not get broken. If you need to use the retry capabilities of the plug-in, either set the ServerIOTimeout property to a non-zero value, use the operating system settings, or use some other non-plug-in mechanism to ensure that you can guarantee that a connection is broken at some predetermined time.
With Version 7.0, the default value of the ServerIOTimeout property is 60 seconds. This might not be the ideal setting for applications running intensive queries or other nontrivial functions. The ServerIOTimeout value will need to be adjusted if you expect requests to take longer than 60 seconds to be served.
The ServerIOTimeout setting is based on how long the server takes to handle a request; not on a particular URI or application. Therefore, when specifying a value for this property, you should allow for the slowest, longest request time, and then add a little more time to handle peak operation situations.
When a request fails because the length of time it took to get a response exceeded the value specified for the ServerIOTimeout property, the server is NOT marked as down if the ServerIOTimeout property is set to a value >= 0. This is an important fact to keep in mind because this fact means that other requests will continue to be sent to this server. If you have affinity defined and this server is selected based on the request's previous session data, the same server will be selected if the request is retried because the server will still be available and matches the incoming affinity requirements. The actual number of times that the plug-in will attempt the request to the same server depends on the number of servers defined in the cluster. If the server is not healthy, sending requests back to the same server is not likely to result in a good response and might exasperate a potential performance problem.
Starting with Version 6.0.2.33, 6.1.0.23 and 7.0.0.3, if you do NOT want the same server selected for affinity requests that fail because of response time-outs or you would like to eliminate traffic from this server because it is not responding within your predefined response criteria, you should specify a negative value for the ServerIOTimeout property. When the value for the ServerIOTimeout property is negative, the plug-in marks the server down when a response time-out occurs. When the plug-in marks the server down, requests will not be sent to that server until the interval specified for the plug-in RetryInterval property expires. If there is only one server in the cluster, it is never marked down regardless of the plug-in properties.
Setting the ServerIOTimeout property to a negative value might have bad consequences if you set the time-out value too low. If you have a long running request that takes longer than the length of the time specified for the ServerIOTimeout property and that request is retried to other servers, the plug-in might mark every server in the cluster down as the request is retried to each server. Therefore, if you specify a negative value for the ServerIOTimeout property, you should ensure that the value specified for the RetryInterval property is within the range such that:

• The lowest value for the range is 1 but this means that the server will only be guaranteed a second to try to recover so the minimum value should be a value that is reasonable for the server to recover.
• The highest value for the range is 1 less than the result of multiplying the absolute value of the setting for the ServerIOTimeout property by one less than the number of servers in the cluster. ((absolute value of the ServerIOTimeout * (number of servers in cluster -1)) - 1

For example, if you set the ServerIOTimeout property to -5, and you have 3 servers in the cluster, the value specified for the RetryInterval property should be between 1 and 9. Specifying such a value guarantees that all of the servers are never marked down because of an unexpected intensive request. If your applications are designed such that a single request can have significant impact on the application server, such as an extensive query which might cause data locking until the query is complete, you should set the ServerIOTimeout property to a very large value, such as 18000 ( 5 hours). If you have selected to mark servers down whenever time-out failures occur, set the RetryInterval to the a value in the minimum recommended range to avoid removing the server from processing requests for a long period of time.

Examples :
The following example illustrates a non-recommended configuration and the potential problem that could arise :
There are 3 servers in the cluster.
The RetryInterval property is set to the default value of 60 seconds.
The ServerIOTimeout property is set to -5 seconds.
An request is made that does not get a response until after 10 seconds elapse.
Assume t is the time the original request is received.
The plug-in sends the request to server 1 and waits 5 seconds for a response. No response is received so server1 is marked down at the time the request was received plus 5 seconds (t + 5).
The request is now sent to server 2, it also fails to receive a response within 5 seconds so the plug-in marks server 2 down at the time the original request was received plus 10 seconds (t + 10).
The request is now sent to server 3 and it fails to get a response so it is marked down at the time the original request was received plus 15 seconds (t + 15).
Because all of the servers are now marked down, all requests will fail until server 1 is retried. Server 1 will be retried at the time the original request was received plus 5 seconds (ServerIOTimeout) plus 60 seconds which is the RetryInterval value (t + 5 +60). Server 2 will be marked as up 5 seconds (t + 10 + 60) later and server 3 will be marked as up 10 seconds (t + 15 + 60) after server 1 is marked as up. There will be 50 seconds where all the servers are marked as down and all requests would fail((t + 5+ 60) - (t + 15)) -- server 1 time marked up minus server 3's time marked down.
The following example illustrates the recommended configuration for the preceding scenario :
There are 3 servers in the cluster.
The RetryInterval property should be set within the range of 1 to 9.
( (number of servers -1 ) x (absolute value of ServerIOTimeout) ) - 1 = (( 3 - 1) * 5) - 1 = 10 - 1 = 9
The ServerIOTimeout property is set to -5 seconds. NOTE: This value is only being used as part of this example. It is not meant to imply that you should specify a timeout value of -5 seconds in all situations. For example this value is not appropriate for the ServerIOTimeout property if you know that some responses will take 10 seconds.
A request is made that does not get a response before ServerIOTimeout pops on server 1.
Assume t is the time the original request is received.
The plug-in sends the request to server 1 and waits 5 seconds for a response. No response is received so server 1 is marked down at the time the request was received plus 5 seconds (t + 5).
The request is now sent to server 2. If the RetryInterval property is set to the minimum recommended value of 1, server 1 will be marked up 1 second after server 2 has received the request (t + ServerIOTimeout + RetryInterval = t + 5 + 1 = t + 6). Server 2 does not get a response and is marked down at the time the original request was received plus 10 seconds (t + ServerIOTimeout to server 1 + ServerIOTimeout to server 2 = t + 10).
The request is sent to server 3. If the RetryInterval property is set to the maximum recommended value of 9, server 1 will be marked up (t+ ServerIOTimeout + retryInterval = t + 5 + 9 = t+14), 1 second before server 3 is marked down (t + ServerIOTimeout to server 1 + ServerIOTimeout to server2 + ServerIOTimeout to server 3 = t +5 + 5+ 5 = t +15) because it fails to receive a response within the ServerIOTimeout property value.
There will never be a time where all servers are marked down because of an unexpected long running request.

Source : http://www-01.ibm.com/support/docview.wss?uid=swg21450051&acss=dakc

WCM API - Deleting and purging Objects

<%@ page import="com.ibm.workplace.wcm.api.*"%>
<%@ page import="java.util.*"%>

<%
// retrieve repository
Repository repository = WCM_API.getRepository();

// get workspace for current user
Workspace workspace = repository.getWorkspace(request.getUserPrincipal());

// Set library
workspace.setCurrentDocumentLibrary(workspace.getDocumentLibrary("WebContent"));

// ********************** Delete \ Purge Content example **********************

// define content
String contentName = new String("Content");
String[] deleteMessage = new String[1];

// find content by name
DocumentIdIterator contentIterator =
workspace.findByName(DocumentTypes.Content,contentName);
DocumentId contentId = null;

if (contentIterator.hasNext()){
contentId = contentIterator.nextId();
// clear all the references of the content
if(workspace.getReferences(contentId)!=null)
workspace.clearReferences(workspace.getReferences(contentId));
// delete content
deleteMessage = workspace.delete(contentId);
out.println("Content deleted :" + deleteMessage);
// purge content
deleteMessage = workspace.purge(contentId);
out.println("
Content purged:" + deleteMessage);
} else {
out.println("Could not delete content :" + contentName);
}

// ****************** Delete \ Purge Library Component example ******************
// define library component
String libraryComponentName = new String("LibraryComponent");
// find library component by name
DocumentIdIterator libraryComponentIterator =
workspace.findByName(DocumentTypes.LibraryComponent,libraryComponentName);
DocumentId libraryComponentId = null;
if (libraryComponentIterator.hasNext()){
libraryComponentId = libraryComponentIterator.nextId();
// clear all the references of library component
if(workspace.getReferences(libraryComponentId)!=null)
workspace.clearReferences(workspace.getReferences(libraryComponentId));
// delete library component
deleteMessage = workspace.delete(libraryComponentId);
out.println("Library Component deleted :" + deleteMessage);
// purge library component
deleteMessage = workspace.purge(libraryComponentId);
out.println("
Library Component purged:" + deleteMessage);
} else {
out.println("Could not delete Library Component :" + libraryComponentName);

}
%>

When tapping into the IBM WCM API do not restrict yourself to a single JSP as this is purely a guideline....imagine this as part of a submission form, values passed to your jsp or servlet and then initiated.

You will soon possess the ability to build a simple yet effective user interface making interacting with WCM easy for any user.

PM00131: NULLPOINTEREXCEPTION IN WEBSPHERE APPLICATION SERVER GENERATED BY OBJECTMANAGER WHEN USING AN SIB FILE STORE.

I am Sharin this PMR as I hae received this question more then once.Hope this helps.

APAR status

• Closed as program error.

Error description

• In WebSphere Application Server, using a SIB messaging engine
  and file store (not a data store), SystemOut.log shows
  CWSIS0002E followed by "CWSOM1015E: ObjectManager", and there
  is a corresponding ffdc file which contains:
  
  Exception = java.lang.NullPointerException
  Source = com.ibm.ws.objectManager.ObjectManagerState:run
  probeid = 1:3061:1.23.1.11
  Stack Dump = java.lang.NullPointerException
  at com.ibm.ws.objectManager.InternalTransaction.
    terminate(InternalTransaction.java:2329)
  at com.ibm.ws.objectManager.ObjectManagerState.
    deRegisterTransaction(ObjectManagerState.java:2045)
  at com.ibm.ws.objectManager.InternalTransaction.
    complete(InternalTransaction.java:2308)
  at com.ibm.ws.objectManager.InternalTransaction.
    backout(InternalTransaction.java:2158)
  at com.ibm.ws.objectManager.
    InternalTransaction$TransactionReference.
    complete(InternalTransaction.java:2762)
  at com.ibm.ws.objectManager.ObjectManagerState.
    completeOrphanTransactions(ObjectManagerState.java:2337)
  at com.ibm.ws.objectManager.ObjectManagerState.
    performCheckpoint(ObjectManagerState.java:776)
  at com.ibm.ws.objectManager.ObjectManagerState.
    access$500(ObjectManagerState.java:52)
  at com.ibm.ws.objectManager.ObjectManagerState$CheckpointHelper.
    run(ObjectManagerState.java:3052)
  at java.lang.Thread.run(Thread.java:810)
  

Local fix

• Restart the server.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:  Users of the default messaging provider for *
  *                  IBM WebSphere Application Server            *
  *                  Version 6.1 or Version 7.0                  *
  ****************************************************************
  * PROBLEM DESCRIPTION: NullPointerException logged to an FFDC  *
  *                      with probeid 1:3061:1.23.1.11           *
  *                      when using the file store               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An FFDC report as follows might be generated from a messaging
  engine using a file store:
  Exception = java.lang.NullPointerException
  Source = com.ibm.ws.objectManager.ObjectManagerState:run
  probeid = 1:3061:1.23.1.11
  
  As a result of this exception, the messaging engine reports
  itself as unhealthy to the application server's high
  availability manager, causing the JVM to be terminated and
  restarted on the next is-alive healthcheck.
  
  The problem occurs because code within the file store
  attempts to access a WeakReference without first checking if
  the reference is null.
  

Problem conclusion

• The fix for this APAR corrects the file store code to check
  the weak reference is not null before accessing it.
  
  The fix for this APAR is currently targeted for inclusion in
  fix pack 6.1.0.31 and 7.0.0.9.  Please refer to the Recommended
  Updates page for delivery information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• APAR number

  PM00131

• Reported component name

  SIBWS

• Reported component ID

  620600100

• Reported release

  200

• Status

  CLOSED PER

• PE

  NoPE

• HIPER

  NoHIPER

• Special Attention

  NoSpecatt

• Submitted date

  2009-10-30

• Closed date

  2009-12-21

• Last modified date

  2009-12-21

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  SIBWS

• Fixed component ID

  620600100

Applicable component levels

• R200 PSY

     UP

How to retrieve a file name stored in WCM library file resource component using the API ReferenceComponent

finds the document id of the content items that match by name 
DocumentIdIterator docIdIterator = ws.findByName(DocumentTypes.Content, "testcontent");
DocumentId docId;
Content currentContent; 


loops through the document id's found in the iterator
while(docIdIterator.hasNext()) 
{
docId = (DocumentId)docIdIterator.next();

get the current content item
currentContent = (Content)ws.getById(docId); 

standard out log message
System.out.println("Log: Testing WCM API: Retrieved content name = " 
+ (String)currentContent.getName());

get the content's component reference element by name
ContentComponent myCmpnt = 
(ContentComponent) currentContent.getComponent("MyComponent");

standard out log message
System.out.println("Log: Testing WCM API: My Component getName = " 
+ (String)myCmpnt.getName());

Typecast using ReferenceComponent in order to access the library component 
stored in the content's component reference element

ReferenceComponent myRefCmpnt;
myRefCmpnt = (ReferenceComponent)myCmpnt;

Get the LibraryComponent which your content is referencing 
LibraryComponent myLibCmpnt = myRefCmpnt.getComponentRef() ;

standard out log message
System.out.println("Log: Testing WCM API: My Library Component name = " 
+ myLibCmpnt.getName());

Use the instanceof method to confirm the library component type. 
For example, this checks if your component is a Library File Component.

if (myLibCmpnt instanceof LibraryFileComponent)
{

In this example, the component reference holds a LibraryFileComponent. 
This will get the file name of the file stored in the LibraryFileComponent.
LibraryFileComponent fileCmpnt;
fileCmpnt= (LibraryFileComponent)myLibCmpnt;

standard out log message
System.out.println("Log: Testing WCM API: My Library File Component: File name = " 
+ fileCmpnt.getFileName() );
} end if statement

Installing WebSphere Application Server version 8 web components

This topic provides instructions for installing new instances of IBM WebSphere Application Server version 8 for use with the RequisiteWeb application server in Rational® RequisitePro® version 7.1.3.1 or later.

About this task

WebSphere Application Server and IBM HTTP Server are installed using IBM Installation Manager. You must install WebSphere and HTTP Server first, and then install Rational RequisitePro web components.

Note: WebSphere Application Server version 8 is not compatible with Rational RequisitePro version 7.1.3.0 or earlier.

You can obtain WebSphere Application Server and HTTP Server V8 from IBM Passport Advantage at http://www.ibm.com/software/passportadvantage. Fixpacks are available from IBM Support Fix Central at http://www.ibm.com/support/fixcentral/.

Here is an overview of the steps you will use to install web server components for Rational ClearCase, Rational ClearQuest, and Rational RequisitePro:

1. Using Installation Manager, install the following products and components:
   • IBM WebSphere Application Server
   • IBM HTTP Server for WebSphere Application Server
   • Web Server Plug-ins for IBM WebSphere Application Server
   • WebSphere Customization Toolbox
2. Run the Web Server Plug-ins Configuration Tool, which is part of the Toolbox, to configure the web server to communicate with the application server.
3. Install or upgrade Rational RequisitePro, including web server components.

Restrictions

Before you begin an installation of WebSphere Application Server version 8, review the following restrictions:

• Prepare your operating system for WebSphere and IBM HTTP Server.
• Refer to technote 1573966 "Known issues and limitations found while installing or configuring WebSphere Application Server and IBM HTTP Server v8.0 to work with IBM Rational ClearCase 8.0.0.1, IBM Rational ClearQuest 8.0.0.1 or IBM Rational RequisitePro 7.1.3.1".
• Do not use symbolic links as the destination directory. Symbolic links are not supported.
• Do not use a semicolon in the directory name. WebSphere Application Server cannot install properly if the target directory includes a semicolon. A semicolon is the character used to construct the class path on Windows systems.
• The maximum path length for the installation location on the Windows Server 2008, Windows Vista, and Windows 7 operating systems is 60 characters.
• Deleting the default target location and leaving an installation-directory field empty prevents you from continuing.

Procedure

To install WebSphere Application Server components:

1. Launch Installation Manager.
2. Select File > Preferences and add the installation repository for WebSphere Application Server in the Repositories section on the Preferences panel.
   Tip: In Installation Manager, select Search service repositories during installation and updates on the Installation Manager Repository preference page. Then, if you are connected to the Internet while you install, you can click Check for Other Versions and Extensions to search for updates in the default update repositories for the selected packages. In this case, you do not need to add the specific service-repository URL to the Installation Manager Repository preference page. Select the fixes to install. Any recommended fixes are selected by default. If there are recommended fixes, you can select the option to show only recommended fixes and hide non-recommended fixes.
3. Click Install at the main Installation Manager screen.
4. At the Install Packages panel, select the following packages to install, and then click Next to continue the installation.
   • IBM HTTP Server for WebSphere Application Server, Version 8.0.0.0 (or later)
   • IBM WebSphere Application Server, Version 8.0.0.0 (or later)
   • Web Server Plug-ins for IBM WebSphere Application Server, Version 8.0.0.0 (or later)
   • WebSphere Customization Toolbox, Version 8.0.0.0 (or later)
5. If you want to install a fix pack for WebSphere Application Server and IBM HTTP Server, such as version 8.0.0.1, select the Check all versions and Check for Other Versions and Extensions check boxes. The fix pack versions are displayed in the list of packages. If they do not appear then the required repository is not included in the preferences; in this case, see Installation Manager tip in step 2. If package list is correct, click Next.
6. If there are any fixes available, you are prompted to choose which ones to install. You should install all listed fixes. Choose the fixes to install and click Next.
7. Accept the license agreement and click Next.
8. At the next panel, you can change the default installation directory by selecting a package group name and specifying a new pathname in the Installation Directory field. Click Next.
   Note: If you change the install location of either the AppServer, Plug-ins, or Toolbox, you might need to make the same change for the others. Do not use locations that are already in use by another version of WebSphere Application Server and IBM HTTP Server on the same machine.
9. Select your translation choices and click Next.
10. At the Select the features to install panel, verify that IBM HTTP Server, IBM WebSphere Application Server, Web Server Plug-ins, and WebSphere Customization Toolbox are selected. Accept default selections. Click Next.
11. On the Configuration for IBM HTTP Server panel, specify your web server configuration.
12. Specify a port number on which IBM HTTP Server will communicate. Use the default port 80, unless you must use an alternate port to avoid a conflict.
13. Choose whether to run the IBM HTTP Server as a Windows service. You can configure the service to run as local system account or a user ID that you specify. The user ID requires the following advanced user rights:
    • Act as part of the operating system.
    • Log on as a service
14. Choose startup type Automatic.
    Important: If you do not select Run IBM HTTP Server as a Windows Service, this instance of IBM HTTP Server cannot be stopped or started by the WebSphere Application Server administrative console. At any time after installation, you can create a new service by running the following command: ihs_root/bin/httpd.exe -n new_service_name -k install and then update the web server definition in the administrative console to reflect the new service name.
15. Click Next. Review the summary information and click Install. When the install completes successfully, you typically see a choice of post-installation tools:
    • WebSphere Customization Toolbox. You need this tool to configure the HTTP plug-ins. This tool must be run on Windows as built-in Administrator or as a local user in the Administrator group. For details, see APAR PM46369.
    • Profile Management Tool. You can use this tool to create a WebSphere Application Server profile if a web component will be deployed into an existing profile.
16. Choose the WebSphere Customization Toolbox to configure the plug-in and click Finish.
    Note: If you do not see an option to run the WebSphere Customization Toolbox, click the Windows Start menu: All Programs > IBM WebSphere > WebSphere Customization Toolbox V8.0 > Tools > WebSphere Plug-ins Configuration Tool.

IBM Customer Experience Suite, IBM WebSphere Portal, and IBM Web Content Manager V8.0

Hey WebSpherians!

So I have decided to venture into the WCM and Portal 8 Realm.Don't forget that I will still be responding to all the WCM/Portal 6 and 7 questions that get submitted.

I decided to add this article plus the source as it does provide some interesting information about my next adventure.

Source :https://www.ibm.com/developerworks/mydeveloperworks/blogs/WebSpherePortal/?lang=en 


Take a look at the latest updates available with the IBM Customer Experience Suite, WebSphere Portal and Web Content Manager Beta Two release. 

This beta release operates on WebSphere Application Server Version 8, and includes updates that can provide your users with a more social, mobile and integrated experience.
Version 8.0 Beta two highlights include

• Managed Pages
  • A simplified way to create and manage portal pages and web content using a new integrated toolbar.
  • New page draft and approval process lets you preview and approve changes to pages before publishing them.
• Site Area Templates
  • Create site area templates that define the authoring settings, such as the design of the form, elements and fields on a form, and default values.
  • Restrict authoring templates usage. For example, use site area templates to only allow "news" items to be created within a "news" site area of a website.
• Enhanced Projects
  • Add users as approvers for a project and send a project through a review state before publishing.
• Simplified Business Process Management
  • Users access relevant tasks and activities for multiple Business Process Management solutions from a single user interface, the Unified Task List portlet.
  • Integrate your site with several Process Management solutions.
• Enhanced SAP integration
  • Support for the new IBM WebSphere Portal Integrator for SAP lets you expose elements from SAP Netweaver Portal directly into WebSphere Portal.
• IBM Installation Manager
  • Manage the software life cycle with a single tool: Install, Update, Rollback, Modify, and Uninstall.
  • Faster installation performance and better integration with other IBM products.
• Social Business in Context
  • New Community Page support lets you more readily scope and place IBM Connections portlets in the right Portal and WCM context.
    • IBM Connections Community Pages portlets are available for Profiles and Blogs with Beta 2.
  • A consistent tagging and rating experience between WebSphere Portal, Web Content Manager, and IBM Connections.
  • OpenID Authentication lets portal users authenticate with public social network credentials, such as a Facebook ID, Google ID or Yahoo ID.

Access the details, Beta software, documentation and support forum here:  http://tinyurl.com/ybmsqkz
 We look forward to your impressions and experiences with the latest updates.

ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

 So WCM 7 Post migration step fail Right?Complaining about access and credentials?

The command you were running:

ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=xxx 

-DWasPassword=xxx -DPreviousPortalVersion=6.1.0.0 -DtransferDomainList=jcr

The Core Error : 

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

The Full write-out in your migration log :

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
Registry could not be loaded from WAS using current connection information.
Please verify your WAS connection properties and retry the operation.  Current input:
WasUserId: xxxxxx


The Solution:

Add the -DWasUserid=user_id  -DWasPassword=password  parameters to the task, and then rerun the task. Verify that the task ran without any exceptions.

Happy Trails!!!

Yours in WebSphere
Jerome Slinger

IBM WCM 6 to 7 Migration - Commands - Unix

Hi Y'all

Please find attached the commands I used during migration form version 6.0.1.X  to 7.0.0.1

• ./ConfigEngine.sh validate-database-connection -DTransferDomainList=jcr -DWasPassword=XXXXXX -DPortalAdminPwd=XXXXXX

• ./ConfigEngine.sh connect-database-jcr-migration

• ./ConfigEngine.sh create-wcm-persistence-tables
• This is not part of the IBM listed steps...you will thank me later :-)

• ./ConfigEngine.sh upgrade-jcr-datastore-601x-to-6100-jcr

• ./ConfigEngine.sh configure-wcm-migration

• ./ConfigEngine.sh configure-wcm-remote-admin

• ./ConfigEngine.sh action-create-schema-applyMIG7000-wp.migration.jcr.db -DPreviousPortalVersion=XXX -DCurrentPortalVersion=7.0.0.x -DWasPassword=Password -DPortalAdminPwd=Password
• Please add your Portal versions where the xx's are.

• ./ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=Password-DWasPassword=Password-DPreviousPortalVersion=6.1.0.x -DtransferDomainList=jcr
• This step fails - Build Failed

The attached error can be found in your migration log.

Error: 

MigrationSQLExecutor: ERROR ->DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, 

SQLERRMC: JCR.ICMSTJCRNODELOCKSX

Migration Log :

/WebSphere/WP_PROFILE/ConfigEngine/log/Migration.log

The Fix:

You can resolve the issue by binding the JCRDB, executing the following commands from a DB2 command line window:

==db2 terminate 

==db2 connect to jcrDB (this is the newly copied database from 6.0.x to 7.0)

==db2 bind PATH\db2schema.bnd blocking all grant public sqlerror continue db2 terminate 

Substitute "PATH" with the install path for your DB2, and make sure you find the db2schema.bnd in the path before running the command.

Also, verify that all the Datasource passwords are correct before running the next task. You can verify this in the security.xml at cell scope:

\config\cells\\security.xml:

Find this entry for the JCR datasource and make sure the encrypted password is the same as the other datasources; if not, set it to the clear text password, and it will be encrypted at the next restart:

authDataEntries xmi:id="JAASAuthData_1296387511109"

alias="jcrdbDSJAASAuth" userId="db2admin" password="setPasswordHere”

description="JAAS Alias for DataSource jcrdbDS"

Happy Trails and Yours in WebSphere

Jerome Slinger

IBM WCM 7 : Migrating from WCM 6.0 to 7 - Release Not Found

Error received during migration: Release not found

Error Example String:

/WebSphere/PortalServer/base/wp.db.impl/config/templates/updatedb/6.0.1.6-7.0.0.1/db2/release

 not found.

Solution:

The issue is caused by missing files for migration from 6.1.0.6 to  7.0.0.1. This happened, because fixpack 6.1.0.6 is newer and so not  known by current 7.0.0.1. An APAR is requested.

As there are no database changes in the affected area between 6.1.0.5  and 6.1.0.6, you could duplicate the files in

/base/wp.db.impl/config/templates/updatedb/6.1.0.5-7.0.0.1

to the new directory

/base/wp.db.impl/config/templates/updatedb/6.1.0.6-7.0.0.1

as a workaround.

This is obviously not ideal but will resolve your problem.

...so how does one end up with this problem.IBM recommends that clients/customers need to be at the most recent fix pack level and as 6.0.1.7 is the most latest users are running into problems.

I hope that this has helped.

Yours in WebSphere

Jerome Slinger

Migration version 6.0 to & - Checking your Versions

Hello Everyone

I am currently busy with a migration from version 6.0 to 7.

Prior to your migration it is important to ensure that you are on the most recent Fixpacks for both your 6 and 7 environment.

Finding your current Portal Version:

On Windows : run %WPS_HOME%\bin\WPVersionInfo.bat (e.g) c:\WebSphere\PortalServer\bin\WPVersionInfo.bat

On Unix : run $WPS_HOME/bin/versionInfo.sh (e.g) /opt/WebSphere/PortalServer/bin/WPVersionInfo.sh

What your report looks like:

--------------------------------------------------------------------------------
IBM WebSphere Portal Product Installation Status Report
--------------------------------------------------------------------------------

Report at date and time 2011-10-06T10:55:59+02:00

Installation
--------------------------------------------------------------------------------
Product Directory /WebSphere/PortalServer
Version Directory /WebSphere/PortalServer/version
DTD Directory /WebSphere/PortalServer/version/dtd
Log Directory /WebSphere/PortalServer/version/log
Backup Directory /WebSphere/PortalServer/version/backup
TMP Directory /tmp

Installation Platform
--------------------------------------------------------------------------------
Name IBM WebSphere Portal
Version 6.0

Technology List
--------------------------------------------------------------------------------
MP installed
PDM installed
WCM installed
PZN installed

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal MultiPlatform
Version 6.0.1.5
ID MP
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Document Manager
Version 6.0.1.5
ID PDM
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Personalization
Version 6.0.1.5
ID PZN
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere WebSphere Portal Web Content Manager
Version 6.0.1.5
ID WCM
Build Level wp6015_008_02
Build Date 11/08/2008

--------------------------------------------------------------------------------
End Installation Status Report
--------------------------------------------------------------------------------

You will notice that my current fix pack level is 6.0.1.5 so it's installing more fixpacks for me :-)

Will add that process as well.

Yours in WebSphere
Jerome Slinger

Preparing to migrate - 6.0.x to 7

Before starting the migration, go through this checklist:

Apply the latest cumulative fixpack on the 7.0 server. Refer to the IBM Support document, “Recommended Updates for WebSphere Portal and Web Content Management V7.0,” for more details.

Both the 6.x and 7.x servers should be using IBM DB2®. We tested these steps using DB2, but you can try the same with other relational databases (CloudScape is not supported).

Back up the JavaTM Content Repository (JCR) database on the 6.x server, and back up all the databases on the 7.0 server. So, in case there is a problem, you can restore the 7.0 databases to their previous working state and start over.

Verify that database-related properties in the Wkplc properties files on the 7.0 server have the correct information on all current databases being used besides the JCR database (JCRDB).

Delete the subscriber and syndicator pairs from the 6.x server before attempting the migration.

Check for any duplicate entries in the JCRSTLINKS table using following query:

select WSID , SIID , TNSID , TNAME , TIX, count(*)
from .ICMSTJCRLINKS
group by WSID , SIID , TNSID , TNAME , TIX having count(*) > 1

If you get any results from the above query, find the content with the name in TNAME column and delete it from the Authoring UI before backing up the 6.x database.

Original Article