Syndication troubleshooting

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

Syndication troubleshooting

This topic contains information to help you troubleshoot syndication issues.

Document (item) errors

The document could not be retrieved from the syndicator by the subscriber:

During the syndication update process, the syndicator sends to the subscriber a package that contains the URLs of all the documents that it needs to retrieve to be up to date. The subscriber works through this package retrieving each document from the specified URL. However, the syndicator may not always be able to dispatch the document. There could be several reasons for this:

The document no longer exists: if this is the case, the next update will send through the deletion notice for the document.
The document could not be retrieved: this could be due to the document being corrupted or not being complete. For example some documents rely on external data for completeness. This includes resources and users. Check the syndicator's document errors and you will find a message describing which document it could not retrieve and why. You will need to correct the data for the document in question to be syndicated.

The document could not be saved by the subscriber:

Once the subscriber has all the documents from the syndicator, it then goes ahead and starts to save them (as long as they are valid replication-wise). Some documents may not save because they are expecting other documents to exist. Check the subscriber's document errors and you will find a message describing which document it could not save and why.

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.
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 Express 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 WebSphere Application Server administrative console. Go to Application Servers > 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...

In the administrative console for WebSphere Application Server, 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.

Parent topic:
Syndication

Document (item) errors	The document could not be retrieved from the syndicator by the subscriber: During the syndication update process, the syndicator sends to the subscriber a package that contains the URLs of all the documents that it needs to retrieve to be up to date. The subscriber works through this package retrieving each document from the specified URL. However, the syndicator may not always be able to dispatch the document. There could be several reasons for this: The document no longer exists: if this is the case, the next update will send through the deletion notice for the document. The document could not be retrieved: this could be due to the document being corrupted or not being complete. For example some documents rely on external data for completeness. This includes resources and users. Check the syndicator's document errors and you will find a message describing which document it could not retrieve and why. You will need to correct the data for the document in question to be syndicated. The document could not be saved by the subscriber: Once the subscriber has all the documents from the syndicator, it then goes ahead and starts to save them (as long as they are valid replication-wise). Some documents may not save because they are expecting other documents to exist. Check the subscriber's document errors and you will find a message describing which document it could not save and why.
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.
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 Express 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 WebSphere Application Server administrative console. Go to Application Servers > 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... In the administrative console for WebSphere Application Server, 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.