Syndication troubleshooting

Syndication troubleshooting

Common issues

Issue Solution
Unable to reach host 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 Syndication can require a large amount of resources to run successfully. Consequently, if the server is performing other tasks at the same time as syndication, the process of syndication may slow or stop altogether. You should schedule the syndication to occur at times when the server load is at its lowest.
Syndicator status hangs on "Pending", or "Pending, Active" If we 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 the 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. 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.
Due to the heavy load of computing these statistics, it is recommenu 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 the IBM WebSphere Portal server can address this issue. The total transaction lifetime timeout setting of the subscriber should be at least the same as the syndicator.
The total transaction lifetime timeout setting is changed using the WAS admin console..

Servers | Server Types | WebSphere appservers | portal_server | Container Services | Transaction Service

Subscriber becomes unresponsive during syndication If we 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:

In the dmgr admin console, click...
System administration | dmgr | Java and Process Management | Process Definition | Java Virtual Machine

Update the value in the Maximum Heap Size field. A value of at least 1024 MB is recommended.

Click OK, and then save the changes.

For portal appservers go to...
Servers | Application Servers | yourPortalServerName | Java and Process Management | Process Definition | Servant | Java Virtual Machine | Maximum Heap Size

...and set the value to a maximum of 768 MB.
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

Option Details
Reset the web content event log. To assist in the troubleshooting process reset the web content event log.
Enable the "deployment.enableReport" setting on the subscriber. We can update the WCM WCMConfigService service and specify the deployment.enableReport property with a value of true. This enables high level reporting of syndication to the SystemOut log on the subscriber server. It provides a summary of items that were processed, and which items failed syndication to help troubleshoot syndication issues.
We can update the WCM WCMConfigService service and specify the deployment.enableReport property with a value of true. This enables high level reporting of syndication to the portal application server job log on the subscriber server. It provides a summary of items that were processed, and which items failed syndication to help troubleshoot syndication issues.

Work with failed items
From time to time items will fail to syndicate. Use failed items view to review a list of failed items and then run syndication again once you have fixed the issue.

Logon to the syndicator as an administrator.

Go to Administration>Portal Content>Syndicators.

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.

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. We can then try to syndicate the failed item again by rebuilding the syndication relationship. Updating the syndication relationship will not retry failed items.

Parent: Administer syndication

Issue	Solution
Unable to reach host	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	Syndication can require a large amount of resources to run successfully. Consequently, if the server is performing other tasks at the same time as syndication, the process of syndication may slow or stop altogether. You should schedule the syndication to occur at times when the server load is at its lowest.
Syndicator status hangs on "Pending", or "Pending, Active"	If we 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 the 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. 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. Due to the heavy load of computing these statistics, it is recommenu 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 the IBM WebSphere Portal server can address this issue. The total transaction lifetime timeout setting of the subscriber should be at least the same as the syndicator. The total transaction lifetime timeout setting is changed using the WAS admin console.. Servers \| Server Types \| WebSphere appservers \| portal_server \| Container Services \| Transaction Service
Subscriber becomes unresponsive during syndication	If we 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: In the dmgr admin console, click... System administration \| dmgr \| Java and Process Management \| Process Definition \| Java Virtual Machine Update the value in the Maximum Heap Size field. A value of at least 1024 MB is recommended. Click OK, and then save the changes. For portal appservers go to... Servers \| Application Servers \| yourPortalServerName \| Java and Process Management \| Process Definition \| Servant \| Java Virtual Machine \| Maximum Heap Size ...and set the value to a maximum of 768 MB. 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.