Syndication troubleshooting

Syndication troubleshooting

+
Search Tips | Advanced Search

If you encounter issues when syndicating, there are some common methods available to troubleshoot these issues.
If the following debugging tips do not work for you, try running JCR Explorer against your JCR database to isolate the problem. See JCR Explorer and XPath for sample XPath queries you can run.

Syndication message catalog

If you encounter issues when syndicating, you should check to see if any of the following messages appear in your log.

Message code Description Solution
The subscriber is not currently valid:

IWKPD1050X

The subscriber is not currently in a state to receive syndication requests from a syndicator because the subscriber is disabled. Enable the subscriber and run syndication again.
Conflicting update:

IWKPD1051X
IWKPD1052X

Sending an update for an item fails because the same item has already been updated on the subscriber. When an item has been updated on more than one server, only the latest change is saved. If the saved change is not the appropriate change, a rollback should be performed. If both changes were valid, you will have to manually merge the changes and republish them.
Duplicate name:

IWKPD1053X
IWKPD1054X

This error occurs when an item being sent conflicts with an item on the subscriber because it has the same name and path. This can occur when a new item is created on multiple servers with the same name and path, or by moving an item to a different parent so that it now conflicts with an existing item. To solve the problem you either:

move one of the items to a different parent.
rename one of the items.

Deleted content:

IWKPD1055X
IWKPD1056X

Sending an update fails because the item has been deleted on the subscriber. To solve this problem:

if the deletion on the subscriber is valid, then delete the item on the syndicator as well
if the deletion on the subscriber is invalid, then restore the item on the subscriber

Missing items:

IWKPD1057X
IWKPD1058X

The referenced item does not exist on the subscriber. There are a number of possible causes:

The referenced item has been purged from the subscriber. You should either re-save the item on the syndicator to recreate it on the subscriber, or remove the reference to the item on the syndicator and purge it there too.
The library containing the referenced item has been deleted from the subscriber. You should either rebuild the deleted library, or move the item to another library that is being syndicated.
The item is in a library that was never syndicated to the subscriber. You should either enable syndication for that library, or move the item to a library that is being syndicated.
The item is in a library that is no longer being syndicated to this subscriber. You should either enable syndication for that library, or move the item to a library that is being syndicated.
The item never got syndicated due to a previous crash or other unknown error. You can either re-save the item so that it gets updated in the next syndication, or rebuild the syndication relationship.

Other issues

If you do not receive any of the messages listed above, then you should check if any of the following issues are applicable.
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.
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 IBM WAS administrative console. Go to Application Servers > server > Container Services > Transaction Service. See the WAS 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:

In the console for WAS, click...
System administration | Deployment manager | 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 your changes.

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

Other

Parent topic
Syndication

Message code	Description	Solution
The subscriber is not currently valid: IWKPD1050X	The subscriber is not currently in a state to receive syndication requests from a syndicator because the subscriber is disabled.	Enable the subscriber and run syndication again.
Conflicting update: IWKPD1051X IWKPD1052X	Sending an update for an item fails because the same item has already been updated on the subscriber.	When an item has been updated on more than one server, only the latest change is saved. If the saved change is not the appropriate change, a rollback should be performed. If both changes were valid, you will have to manually merge the changes and republish them.
Duplicate name: IWKPD1053X IWKPD1054X	This error occurs when an item being sent conflicts with an item on the subscriber because it has the same name and path.	This can occur when a new item is created on multiple servers with the same name and path, or by moving an item to a different parent so that it now conflicts with an existing item. To solve the problem you either: move one of the items to a different parent. rename one of the items.
Deleted content: IWKPD1055X IWKPD1056X	Sending an update fails because the item has been deleted on the subscriber.	To solve this problem: if the deletion on the subscriber is valid, then delete the item on the syndicator as well if the deletion on the subscriber is invalid, then restore the item on the subscriber
Missing items: IWKPD1057X IWKPD1058X	The referenced item does not exist on the subscriber.	There are a number of possible causes: The referenced item has been purged from the subscriber. You should either re-save the item on the syndicator to recreate it on the subscriber, or remove the reference to the item on the syndicator and purge it there too. The library containing the referenced item has been deleted from the subscriber. You should either rebuild the deleted library, or move the item to another library that is being syndicated. The item is in a library that was never syndicated to the subscriber. You should either enable syndication for that library, or move the item to a library that is being syndicated. The item is in a library that is no longer being syndicated to this subscriber. You should either enable syndication for that library, or move the item to a library that is being syndicated. The item never got syndicated due to a previous crash or other unknown error. You can either re-save the item so that it gets updated in the next syndication, or rebuild the syndication relationship.

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. 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 IBM WAS administrative console. Go to Application Servers > server > Container Services > Transaction Service. See the WAS 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: In the console for WAS, click... System administration \| Deployment manager \| 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 your changes. In addition, ensure that you have at least as much swap space allocated on the subscriber machine as you have physical memory.