Staging: Syndication troubleshooting

If you encounter issues when syndicating, there are some common methods available to troubleshoot these issues.

Common issues

Table 1. Common issues
Issue Solution
Unable to reach host This is a common reason why syndication does not work. The URL for the syndicator or the subscriber may not be valid. You may need to use the IP address rather than the domain name.
Syndicator becomes unresponsive during syndication

Syndication can require a large amount of resources to run successfully. Consequently, if your server is performing other tasks at the same time as syndication, the process of syndication may slow or stop altogether. You should schedule your syndication to occur at times when the server load is at its lowest.

Syndicator status hangs on "Pending", or "Pending, Active"

If you are attempting to update or rebuild a syndicated library containing large number of items, the syndicator status might hang on "Pending", or "Pending, Active". This can occur because the syndicator keeps retrying to syndicate when some items fail to syndicate to the subscriber, or when a system timeout occurs on the subscriber when saving data.

Improving the performance of your database can help avoid these situations. For example, two of the database attributes that DB2 relies upon to perform optimally are the database catalog statistics and the physical organization of the data in the tables. Catalog statistics should be recomputed periodically during the life of the database, particularly after periods of heavy data modifications (inserts, updates, and deletes) such as a population phase. In order to fix this, you should run "Runstats" on the JCR database before and after syndication. The DB2 runstats command is used to count and record the statistical details about tables, indexes and columns. See Database performance for information on using the "Runstats" task.

Due to the heavy load of computing these statistics, it is recommend that this maintenance occurs during off hours, periods of low demand, or when the portal is off-line.

Time-outs during syndication Time-outs during syndication are often caused by the failure of large items to be saved. Increasing the total transaction lifetime timeout setting of your IBM® WebSphere® Portal server can address this issue. The total transaction lifetime timeout setting of your subscriber should be at least the same as the syndicator.

The total transaction lifetime timeout setting is changed using the WebSphere Integrated Solutions Console..

Go to Servers > Server Types > WebSphere application servers > portal_server->Container Services > Transaction Service.

See the WebSphere Application Server information center for more information.

Subscriber becomes unresponsive during syndication If you are attempting to syndicate a library containing more than 10000 items, the subscriber machine might become unresponsive during the syndication operation. This can occur due to an insufficient Java heap size setting on the subscriber.
To update the maximum Java heap size used by the portal application server on the subscriber machine, complete the following steps:
  1. In the WebSphere Integrated Solutions Console, click System administration > Deployment manager > Java and Process Management > Process Definition > Java Virtual Machine.
  2. Update the value in the Maximum Heap Size field. A value of at least 1024 MB is recommended.
  3. Click OK, and then save your changes.
  1. In the WebSphere Integrated Solutions Console, select Servers > Application Servers > yourPortalServerName > Java and Process Management > Process Definition > Servant > Java Virtual Machine > Maximum Heap Size to set the JVM heap size.
  2. Set the value to a maximum of 768 MB.
  3. Click OK, and then save your changes.

In addition, ensure that you have at least as much swap space allocated on the subscriber machine as you have physical memory.

Syndication takes a long time to complete on z/OS® systems. When running syndication with a large amount of data, the z/OS database 4k buffer pool, 4k index buffer pool and the 32k buffer pool will need to monitored and increased as necessary. Increase of these buffer pools will make significant impact on syndication performance. See Preparing DB2 for z/OS for further information.

Other solutions

Table 2. Other solutions
Option Details
Resetting the web content event log. To assist in the troubleshooting process you can reset the web content event log. See Resetting the web content event log for further information.

Working with failed items

From time to time items will fail to syndicate. You use the failed items view to review a list of failed items and then run syndication again once you have fixed the issue.
  1. Logon to your syndicator as an administrator.
  2. Go to Administration>Portal Content>Syndicators.
  3. The number of failed items for a syndicator are displayed in the Failed Items column. Click on the number of failed items to open the Failed Items view.
  4. Each failed item for the selected syndicator is displayed in the Failed Items view. The reason for the failure is displayed against each failed item along with a message catalog code. Look up the code in the message catalog and take the appropriate action to fix the issue. You can then try to syndicate the failed item again by rebuilding the syndication relationship. Updating the syndication relationship will not retry failed items.