ShowTable of Contents
JavaTM Content Repository FAQS
How is content stored in the JCR tables, nodes, and UUIDs?
Content is stored in the repository against a complex schema of interrelated tables. Each node is modeled through a graph of information stored across multiple tables. For this reason, deleting a node is not as simple as removing one row from a table in the database. The interrelated connections between all the tables must be handled. In many cases, the level of logic required is not encoded in any singular SQL command that can be sent to the database.
Does IBM® publish the JCR database schema?
No. The data in the JCR is separated across several tables in the database. There is no simple correlation between the IBM Lotus® Web Content ManagementTM (WCM) objects and database tables or rows.
What data can be safely deleted from the database without causing corruption
In most cases there is not a simple SQL statement that can be constructed to fix an application issue. The context or semantics for functions are encoded in the application and not the database itself.
What is a "workspace"?
A workspace can be thought of as a view with a stored userID/password. Within the JCR specification, the concept of a workspace is defined as a container for a collection of nodes. The content repository is divided into the following hierarchy:
1. Repository - Container for workspaces
2. Workspace - Container for nodes
3. Node - Container for properties
4. Property - Attribute of node
All work in the repository is done by means of a workspace. When a user logs into the repository, a "ticket" is issued, through which the user requests a workspace. It is through the workspace that all interaction with the nodes, or content, is performed. All modifications to nodes within a workspace is transient until a save operation. The workspace save operation persists all changes made to the nodes within the workspace to permanent storage, the database.
What are dynamic workspaces?
Changes to a regular workspace are not persisted to the backend data store until save is called on the workspace. A dynamic workspace is a workspace created from a regular workspace. It contains all the nodes that exist in the regular workspace. However, this sandbox is even more specialized because any changes made to nodes can be persisted by way of a save operation called on the workspace to the backend data store.
NOTE: Changes made to the dynamic workspace are NOT made to the stable workspace. The changes made in a dynamic workspace are merged into the backing stable workspace when a merge operation is called.
What kind of user permissions are given by default to a workspace?
A workspace itself does not have access/permissions associated with it. All authorization decisions within the repository are made against the nodes in the workspace. Therefore, if an operation is requested within a workspace, the authorization check is made against the nodes involved in the operation. There are no workspace authorization checks.
Does each logged-in user get a workspace or is the workspace shared?
Within the repository there is only one workspace with a given name. However, every user who logs into the repository and requests a workspace with a given name is given a distinct Java object to represent it. Thus, each user has his/her own personal playground copy of that workspace. Their changes are persisted only if a save is performed on the workspace object.
NOTE: Applications above the repository may choose to share or cache the workspace object in their own manner.
How do you back up and restore the database?
Each database provides its own tooling to accomplish a backup or data restore of a database instance. The database administrator should have a regular process of backup for the repository database, along with the other Portal databases. In the event of a catastrophic failure, a restore may be the shortest path to recovery of the data in the system.
NOTE: Restoring data from backup does not solve the root cause of problems affecting the application server itself. For Cloudscape, a backup can be as simple as creating a .zip file archive of the directory structure that contains the database. For the other database platforms, use the associated vendor tools. A database administrator should be familiar with how to use them.
How many characters are allowed for a user ID in JCR?
For WebSphere® Portal 6.0.1.x and earlier, there is a limit of 32 characters for user IDs that are using JCR.
For WebSphere Portal 6.1 and later, the user ID length can be up to 175 characters.
How do you change the database access rights after the JCR database has been created?
For details on how to do this, refer to the following documents:
Document #1255441 "DB2 Rights for the Portal Runtime Database User". This technote is not published external to IBM. Please contact IBM Support to obtain a copy.
Document #125542 "DB2 for z/OS Database Rights Definition for the Portal Runtime Database User."
What character sets are required for the JCR database?
All databases must be created using Unicode and national character sets such as UTF8, AL32UTF8, or AL16UTF16.
A. First, install the latest JCR cumulative fix, if possible:
1. To see the current recommended JCR cumulative fix, refer to Document #700763, "Recommended fixes and updates for WebSphere Portal and Web Content Management.
2. Select the appropriate product version and then search the page for "JCR".
B. Then download the Support Tools Portlet from the IBM Lotus and WebSphere Portal Business Solutions Catalog here:
Install the portlet and place on a test page. This portlet is helpful in understanding the structure of the JCR database and is invaluable in troubleshooting many Web Content Management and JCR issues.
Some features of the portlet are not enabled due to the risk of database corruption if misused. Product Support will provide codes valid for the current week to enable these additional features, if necessary to troubleshoot an issue effectively.
It's also possible to run XPath queries that are pulled from a JCR trace and pasted into the Support Tools Portlet.
C. Collect a JCR trace:
1. Delete any trace*.log files in the WebSphere Portal log directory as follows:
# For 6.1.x ...websphere/wp_profile/logs/WebSphere_Portal/
# For 6.0.x ...websphere/Portalserver/log/
2. Log into WebSphere Portal with the Portal admin user ID.
3. Open a second tab in the same browser and copy/paste the URL from the first tab as the URL for the second tab.
4. Navigate to the point in the first tab just before the problem is reproduced and stop at that point.
5. In the second tab, enable the trace by selecting Administration --> Portal analysis --> Enable tracing.
6. Add the tracestring below in the "Append these trace settings" field and click the "+" icon:
7. Reproduce the problem in first tab and remove the tracestring.
JCR performance issues
To troubleshoot JCR performance issues, start with Document #1322147, "JCR Troubleshooting topic: query performance and XPath."
Once the long-running queries have been identified, either work with the application to reduce the size or complexity of the query sent to JCR, or optimize the database server to reduce the time to process the query.
To optimize the database server performance, start with the WebSphere Portal Family wiki article, "Tuning Recommendations for Web Content Management."
One approach that can help with query optimization is to extract the query from the trace and run it from the command line. For some queries all values are populated in the trace, but for other queries the "host variables" are missing and replaced by a "?" in the trace.
When this occurs, first check the trace entries below the query to see if the values that should be substituted for the "?" are present. If not, temporarily configure the portal to output the "host variables" in the trace, using the following procedure:
1. Stop the WebSphere Portal Server.
2. Edit file /jcr/lib/com/ibm/icm/icm.properties and add/set the following property:
Note that the value above must be set to "+" and not to "true".
3. Set the trace to com.ibm.icm.*=all in the WebSphere Application Server admin console, if trace is required during WebSphere Portal startup. Otherwise, use the dynamic instructions in the "Collect a JCR Trace" section above.
4. Restart WebSphere Portal.
Once the query is reproduced from the command line, work with your database administrator(DBA) to analyze database performance. In many cases, the DBA can identify a new index that will help reduce the time to process the query.
An example of this error is
"com.ibm.icm.jcr.access.AccessDeniedException: The requested operation violates one or more lock constraints.: [ErrorCode:7591]"
An AccessDeniedException error from WCM can mean one of the following:
o The logged-in user does not have available WebSphere Portal Access Control for this object. This is a valid exception if the user does not have the correct access rights for the requested action. The administrator must grant the necessary rights through WebSphere Portal for that object and action.
o The JCR node is locked by another workspace. If the internal locks indicate that the node is locked by a draft workspace, this is a common occurrence if the content node has a pending draft. In this case, the next step is to remove the content node and its drafts.
o The JCR node is locked by another user. If the external locks indicate that the node is locked by another user and the lock details shows the lock user’s ID, the next step is to log in as that user and unlock the node(s).
If you are unsure of the current lock status, use the Support Tools Portlet referenced above to locate the node(s)and their locks. The Display Node JSP of the WCM Support Tools portlet will display all the locks for the specified node and its children. Any of the nodes that are locked will be shown in the portlet as either "external" or "internal".
Use the following steps in the Support Tools Portlet to display the node and its locks:
1. Launch Utility JSP's.
2. Select the Display Node option.
3. Enter the following values:
# The node by path or UUID
# Show Node's Children
# Show Node's Locks
Examples from trace:
[datetime] 0000006d NodeImpl 3 com.ibm.icm.jcr.NodeImpl checkPermissions(8) Checking permissions: 8 on node: /contentRoot/icm:taxonomy/.system/com.ibm.portal.policy for user: uid=wpsadmin,o=defaultWIMFileBasedRealm
[datetime] 0000006d NodeImpl 3 com.ibm.icm.jcr.NodeImpl checkPermissions(8) Permissions not granted. Current permissions: 0
NOTE: Permission 8 is READ permission.
The JCR node is locked by another workspace. Here's an example trace for this issue:
NodeImpl 3 com.ibm.icm.jcr.NodeImpl save(false, false) Found lock on path: /contentRoot/icm:libraries/Content/mysite/welcome owned by: Workspace 7c2ba800465031b597d5f719fed3c258
SystemErr R com.ibm.icm.jcr.access.AccessDeniedException: The requested operation violates one or more lock constraints.: [ErrorCode:7591]
This is a common occurrence if the content node is being held by another draft. In this case, delete the draft before proceeding. When the draft is deleted, JCR will remove the draft workspace.
NOTE: Try using the application user interface (WCM Authoring Portlet) to delete the draft workspaces.
If you are unable to unlock the node through the Authoring UI, use the Support Tools Portlet to remove the locks for that node:
1. Enable Write Access, using the unlock access code available from WCM Product Support.
2. Select Home > Launch Utility JSP's > Display Node and Unlock.
3. Enter the following values:
# The node by path or UUID
# Show Node's Children
# Show Node's Locks
# Unlock Node's External Lock
Occasionally a problem will occur after a failed library delete, in which drafts are still left in the library. In this case, use the Support Tools Portlet or manageDrafts.jsp to delete the drafts and their associated workspaces. (Contact Product Support for a copy of manageDrafts.jsp.)
If the JCR node is locked by another user, it is common for that user to be working on the same node. This is considered normal behavior. The best action for this failure is to log in as the other user and unlock the node.
AccessDeniedExceptions can occur during import-wcm-data. Lock exceptions during import-wcm-data are caused by leftover locks from the export. The solution is to remove the locks during export, using the steps below:
1. Edit the file /jcr/migration/conf/wcm60_conf.xml, replacing the "serializer" property (at around line 100) with the following:
<!-- The class name for the serializer instance to be used -->
<!-- property name="serializer" value="com.ibm.icm.jcr.serialization.serializer.ext.WPSDocLibNodeSerializerImpl"/ -->
<property name="serializer" value="com.ibm.icm.jcr.serialization.serializer.ext.WPSNoLockDocLibNodeSerializerImpl"/>
2. Export the library again to an empty directory.
3. Retry the import based on the new export directory.
JCR throws an ItemNotFoundException when the requested node cannot be located, for example:
This issue can have two causes:
# The requested node does not exist in the repository.
# The current user does not have sufficient access to read the requested node.
First verify that the user has access to the requested nodes in WebSphere Portal, and then contact the application's Support team as to why the requested node was not saved in the repository.
This is a normal exception by JCR and does not indicate a JCR failure. StaleValueException is thrown when the current node being saved is different from the latest version of that node in the database. To resolve the issue:
1. Locate the DBAccessException in the logs, for example:
[datetime] 000000c4 PUpdateNodeIm E PUpdateNodeImpl persistUpdatedContents Error while calling a function updateItems of PLS data manager.
com.ibm.icm.da.DBAccessException: [ErrorCode:10024] Error, item AB001001N10C04B700000C61D9, versionID=1 (userTable=ICMUT01074001) is stale, timestamp mismatch: datetime1, datetime2
2. Compare the two timestamps in the timestamp mismatch in the exception text:
For example, are they exactly one hour apart (2/28/10 10:00 AM, 2/28/10 11:00 AM)? There is a known issue with JCR nodes that have been created or updated within the first hour after the time switch to Daylight Saving Time (DST).
The cause of this problem is that Java compensates for DST differently from the database. During this hour of overlap, Java advances internal timestamps one hour. However, the database does not advance the timestamp during this period, resulting in an inconsistency between Java timestamps and database timestamps. The end result is that users encounters a StaleValueException every time they try to update nodes from this hour of overlap.
This DST issue is addressed by applying the latest JCR Cumulative fix for portal version 6.1.x or applying APAR PM11951 for portal version 6.0.x.
We have also encountered a StaleValueException that is caused by problems in Oracle JDBC drivers prior to version 10.2.0.5. If you receive a StaleValueException related to DST and the above ifixes have been applied, make sure the Oracle driver is at the correct level.
Are the timestamps different values but not one hour apart? This is the exception caused by normal processing. Retry the operation and make sure that no other user is updating the same content at the same time. If the problem persists, contact the application's Support team (Web Content Management, Personalization, Portal Document Manager, etc.).
Are they the same value (for example, 2/28/10 12:00 AM, 2/28/10 12:00 AM)? A problem has been observed on Oracle servers in which the Oracle database saves an invalid timestamp. This results in a StaleValueException from JCR because the Java cannot correctly read the invalid timestamp(s). Two options are available to address the case where the timestamps are the same:
1.Apply JCR APAR/Fix PM32598
2.Use the steps below to force a resave of the data:
1. Install the Support Tools Portlet (version 1.0.5 or later).
2. Set the access code for update (available from Product Support).
3. Search for the document by IID from the DBAccessException (for example, AB001001N10C04B700000C61D9 in the example in Step 1).
4. Edit the node and save it.
5. If the node is WCM content, update the node in WCM Authoring Portlet to verify that the data is saved correctly.
A javax.transaction.RollbackException indicates that a previous failure has occurred and the current database transaction is being rolled back. Find and troubleshoot the previous failure.
For DB2® users, also check the db2diag.log file for the previous exception(s).
To troubleshoot a database deadlock:
1. Ensure the database statistics are current.
2. Verify the number of database connections and webcontainer threads. A deadlock in the Java Runtime Environment (JRE) can occur if there are fewer database connections than webcontainer threads in the configured WebSphere Portal server. For more information, refer to Document #1292738, "Unable to locate Dynamic Workspace."
3. Verify the deadlock exceptions in the trace, for example,
"SQL0913N Unsuccessful execution caused by deadlock or timeout." or
"COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/AIX64] SQL0913N Unsuccessful execution caused by deadlock or timeout. Reason code "68"." The error description can be found in the DB2 Information Center. The issue is caused by either a deadlock or a lock timeout:
# Reason Code "2": Deadlock
# Reason Code "68": Timeout
Also, note that "Server returned XA_RBDEADLOCK" is an example of a deadlock message from an XA connection.
4. Increase the DB2 lock timeout and verify the results. For more information, refer to the DB2 Information Center topic, "SET CURRENT LOCK TIMEOUT statement."
5. Obtain deadlock diagnostic information:
a. Verify that the deadlock message(s) in the WebSphere Portal logs identify the tables involved.
b. Recreate the failure with JCR trace enabled (see the JCR Trace section above).
c. Obtain a database snapshot of the failure. Note that the snapshot specifics vary based on database platform, so refer to the documentation for the database server (DB2, Oracle) for specific information.
JCR throws this exception when an error has occurred, rendering the current log-in session invalid. For example:
"com.ibm.icm.jcr.InvalidWorkspaceException: Instance of workspace ROOTWORKSPACE has been marked invalid and should be discarded."
To correct the problem, log out and then log in. Note that this exception does not require data in the repository to be deleted.
IMPORTANT: InvalidWorkspaceException is an indication that a previous problem has left the current log-in session invalid, so be sure to identify and address the original problem.
There are often cases in which the OutOfMemoryError is caused by the application processing too much data when using a StrongWorkspaceState. You can identify this when you see StrongWorkspaceState holding a lot of memory in the heap dump analysis.
The StrongWorkspaceState is an internal cache of all JCR nodes referenced in the current workspace. The OutOfMemoryError here indicates that more nodes are referenced than the current memory can handle. Therefore, the application must be changed to do one of the following:
1. Reduce the number of nodes processed per workspace.
2. Manually clear the workspace state at an interval that can be handled by the system's memory.
3. Use Weak workspace state.
The latest JCR cumulative fix for WebSphere Portal 6.0.1 and 6.1 contains a fix that helps identify the application that is improperly using the StrongWorkspaceState. It does not resolve the problem. However, if you enable trace to "com.ibm.icm.jcr.StrongWorkspaceState=all" and recreate the failure, then after the next OutOfMemoryError the trace will contain debug stack traces that can be used by Product Support to identify the failure.
Otherwise, this error needs more diagnostic information to determine the cause. You must collect Java cores and the heap dump of the failure, which will show the objects that are consuming the memory during the time of failure.
JCR throws a ReferentialIntegrityException when the application attempts to remove a node that contains an outstanding reference, for example:
"javax.jcr.ReferentialIntegrityException: Path Add/Rename/Delete operation failed; Deleted item: AB001001N07L28C22602B8A3B7 is still referred by: AB001001N07L28C217029035B7 version: 3"
All references to the node must be removed before removing the node itself. To resolve the issue, locate and remove the outstanding references, following these steps:
1. Locate the IID values from the error message (for example, 'AB001001N07L28C22602B8A3B7' and 'AB001001N07L28C217029035B7')
2. Install the Support Tools Portlet.
3. Browse nodes, and lookup the nodes by IID.
After identifying the nodes involved with the exception, use the application (WCM Authoring) to remove the reference.
Non-atomic batch failure
To troubleshoot a non-atomic batch failure:
1. Make sure the latest cumulative fix is applied (see above), to ensure diagnostic information for the Non-atomic batch failure is available.
2. Enable JCR Trace (see above) and recreate the failure.
3. Look in the logs for the database exception. The actual exception is included in the trace immediately before the Non-atomic batch failure.
To troubleshoot database exceptions:
1. Ensure that the tables are part of JCR. JCR Tables start with ICM* and TSS*. Note that other applications (including WCM and PAC) store data in the JCR database.
2. Get the exception and stack trace from the logs, for example:
[datetime] 0000005a PGetItemsByCM E Error while calling a function retrieveItemsByCMId of PLS data manager.
com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC:
3. In the case of DB2, translate the SQLCODE value. The explanation for each SQLCODE is documented in the DB2 Information Center. For example, the DB2 exception
"com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC:" translates to the following description:
"SQL0104N An unexpected token was found following text. Expected tokens may include: token-list."
4. In the case of SQL Server on WebSphere Portal 6.0.1.x, verify lowercase schema issues by confirming that PK87097 (PORTAL 6.0X DOESN'T SUPPORT LOWERCASE SCHEMA NAME IN MS SQL) is applied.
Here are some other issues and their resolutions:
DB2 Database hangs during WebSphere Portal upgrade.
There have been issues in which a database hang occurs while upgrading WebSphere Portal versions (such as upgrading to 18.104.22.168). This can be caused by the database user not having DBADM authority. Note that it is not enough to grant only SYSADM authority to the use. The user must have explicit DBADM authority.
SQLSTATE=54001 - The statement is too long or too complex.
Increase the values of the DB2 statement heap (stmtheap), the application heap (applheapsz), and the cache size (pckcachesz), and then restart the Database Manager for these updates to take effect. If this failure occurs during a one-time operation, such as library delete, it's OK to reduce these values after the delete has completed.
In addition, this error can occur if database statistics are not regularly executed. Make sure the database statistics are current. Refer to the Database performance topic in the WebSphere Portal Information Center for more information.
SQLCODE 805 - Missing database package.
"DB2 SQL error: SQLCODE: -443, SQLSTATE: 38553, SQLERRMC:SYSIBM.SQLTABLES;TABLES;SYSIBM:CLI:-805"
This indicates a need to bind the db2schema.bnd file against each database by entering the following commands at a DB2 command prompt:
db2 connect to database-name
db2 bind path\db2schema.bnd blocking all grant public sqlerror
where "database-name" is the name of the database to which the utilities must be bound, and "path" is the full path name of the directory where the bind files are located.
SQLCODE 302 (host variable is too large) during query.
"com.ibm.icm.da.portable.query.Query openQueryCursor() com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -302, SQLSTATE: 22001, SQLERRMC: null"
This exception can occur if the XPath query specifies invalid properties, causing the database to throw this exception when trying to execute the invalid query. If this exception is encountered, obtain a JCR trace and verify that the XPath query does not attempt to query invalid properties.
Failure to create database
The prefix must be unique enough to contain only the databases used for the content repository. Always use a prefix that provides unique database name conventions (for example, DPTJCRXXX, or something similar).
Note that this problem can also appear during database transfer, when JCR is attempting to write to the wrong database. This is another case in which the jcr.ZosDbPrefix is not unique.
Pause during database transfer
WebSphere Portal 6.1 has a pause option for the database transfer, allowing the administrator to customize the generated DDL before it is applied to the database. Enable the pause feature by adding "-DTransferPauseEnabled=true" to the database-transfer command.
Error with ordered results
There is a known defect with ordering on Oracle 22.214.171.124, in which an ordered list from JCR may not be returned in the correct order. Upgrade to Oracle 10.0.2.3 or later to resolve the problem. For more information, refer to the Document #1266428, "Menu ordering is broken in Web Content Management (WCM) due to bug in Oracle."
Example error: "ORA-04098: trigger 'ICMADMIN.TSPEND_IWS2' is invalid and failed re-validation"
This issue occurs when the triggers are created in the incorrect schema. This has been fixed with PK48092, but the problem may still occur after a database is transferred to Oracle before applying PK48092.
NOTE: PK48092 is included in the latest JCR cumulative fix for WebSphere Portal 6.0.1.x and is not needed for Portal 6.1.
To resolve the problem, verify the following:
o The defined JCR schema in /jcr/lib/com/ibm/icm/icm.properties
o That the trigger exists: .TSPEND_IWS2
Findthe name of the schema that's defined in icm.properties, and replace TSPEND_IWS2 with the name of the missing trigger.
o That the other JCR tables are in the same schema:
SELECT COUNT(*) FROM .ICMSTJCRNODELOCKS
After verification, move the triggers to the same schema as the JCR tables if they are not already there.
For more details, refer to Document #128863, "DSRA0304E, DSRA0302E, WTRN0037W errors occur during startup after Portal transfer to Oracle."
PK87097: Make 6.0x fault tolerant of lowercase schema.
This fix allows WebSphere Portal 6.0.1.x to be tolerant of lowercase database schema and is part of the latest JCR cumulative fix.
Database constraint failures on ICMSTJCRNODELOCKS.
"SQL error : SQL0803N: One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "1" constrains table "JCR.ICMSTJCRNODELOCKS" from having duplicate values for the index key."
This exception can be seen in the FFDC logs. It's part of normal processing and does not indicate a failure.
Unable to extend index ICMADMIN.xxxx by nnn in tablespace yyyy ORA-06512: at line 1.
Here the DBA needs to increases the size of tablespace yyyy.
"Caused by: com.ibm.websphere.ce.cm.DuplicateKeyException: DB2 SQL Error: SQLCODE=-803, SQLSTATE=23505,SQLERRMC=6;JCR.PROT_RES, DRIVER=3.57.110"
This is expected behavior when trying to create the same node, such as /.personalization in more than one workspace, such as ROOTWORKSPACE and RULESWORKSPACE. Please ensure that this node (/.personalization) has been completely removed from all workspaces before continuing.
Database connection issues:
"com.ibm.websphere.ce.cm.StaleConnectionException: No more data to read from socket"
This problem has been seen on Oracle 10.2.0.2 and is an Oracle problem. Oracle Support recommends upgrading to version 10.2.0.3.0.
com.ibm.db2.jcc.c.SqlException: Invalid operation: result set closed
This problem can occur when another process closes all database connections. It's often accompanied by NullPointerException messages within JCR, as JCR has now lost the database connection in mid-process. Instances of this problem have been resolved with PK60501 from WCM.
com.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is closed
This error indicates that the Java Database Connectivity (JDBC) connection to the database has been closed elsewhere. Applying the latest JCR cumulative fix may help with the issue.
Connection Manager received a fatal connection error from the Resource Adaptor for resource jdbc/wpdbDS. The exception which was received is com.ibm.websphere.ce.cm.StaleConnectionException: IBM CLI Driver SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS".
Location where the error was detected: "10.3.42.30". Communication function detecting the error: "send". Protocol specific error code(s): "32", "*", "0". SQLSTATE=08001
"SQL30081N RC 32" signifies a broken pipe between the DB2 client driver and DB2 server. In the case of one user, the issue was due to a network error and required an AIX patch.
JCR Text Search Troubleshooting
About the author
John Rickett is a Staff Software Engineer and is currently a JCR SME for the Web Content Management L2 Team.