Syndication troubleshooting
If you encounter issues when syndicating, there are some common methods available to troubleshoot these issues.
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 might not be valid. You might 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 might slow or stop altogether. You must 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 that contains 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 must 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 must 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 offline. |
| 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 HCL Digital Experience server
can address this issue. The total transaction
lifetime timeout setting of your subscriber must be at least
the same as the syndicator. The Go to . See the WebSphere® Application Server information center for more information. |
| Subscriber becomes unresponsive during syndication | If you are attempting to syndicate a library
that contains more than 10000 items, the subscriber machine might
become unresponsive during the syndication operation. This action
can occur due to an insufficient Java heap size setting on the subscriber. To
update the maximum Java heap size that is used by the portal application
server on the subscriber machine, complete the following steps:
In addition, ensure that you have at least as much swap space allocated on the subscriber machine as you have physical memory. |
| 500 errors on ext2 and ext3 versions of Linux | If you receive 500 errors on ext2 and ext3 versions of Linux, you exceeded the number of children that a parent folder can hold. You cannot store more than 32768 children under one folder on ext2 and ext3 versions of Linux. Move some content items out of the affected site area to another site area. So that none of your site areas contain more than 32768 children under one folder and then try syndicating again. You can move the content items back to the correct site areas after syndication is complete. |
| Subscriber is successful but syndicator is pending with no updates or failed items | Verify that the subscriber URL is correct.
For example, the subscriber URL might be one of the following URLs:
Note: In some configurations, TAM automatically appends itself
to the subscriber URL, as in the following example:
|
| Syndication takes a long time to complete on z/OS® systems. | When you run syndication with a large amount of data, the z/OS® database 4k buffer pool, 4k index buffer pool, and the 32k buffer pool need to be monitored and increased as necessary. Increase of these buffer pools make significant impact on syndication performance. For more information, see Preparing DB2 for z/OS. |
| Manual syndication is automatically started when subscriber is restarted. | If you want to avoid this behavior, set the following property in the
WCMConfigService in the WebSphere® Application Server console of the
subscriber server and restart portal:
|
Other solutions
| Option | Details |
|---|---|
| Resetting the web content event log. | To assist in the troubleshooting process, you can reset the web content event log. For more information, see Resetting the web content event log in the related links. |
Working with failed items
From time to time items fail to syndicate. You use the failed items view to review a list of failed items and then run syndication again after you fix the issue.- Log on to your syndicator as an administrator.
- Click the Administration menu icon. Then, click .
- The number of failed items for a syndicator are displayed in the
Failed Items column. Click 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. Information is displayed about each failed item, including information about how the appropriate action required to fix the issue.
- The Root and Impact columns are used to find the root cause of a syndication failure, and what secondary items are impacted by the root cause. By finding and fixing the root cause of the syndication failure, you also potentially fix the syndication failures of the items that are impacted by the root cause.
- The Important Items tab can also be used to narrow down which items are the most crucial to fix.
- After you identified and fixed the issues, you can click Retry to initiate syndication for individual items, or use the Retry All in the Important Items tab to try to syndicate all failed items. You can also choose to update or rebuild a syndication relationship.