Product DocsMenu

Troubleshooting Jive 5/SBS/Clearspace Connector Issues


The following sections describe general issues you may encounter while using the Jive 5/SBS/Clearspace connector and attempts to provide the best course of action to resolve them.

Group Permissions

Changes to some group permissions within Jive are not effective in CES, even after security the cache was updated

Permissions in Jive are flexible. They support users and groups, use inheritance to propagate through sub-communities, and support a hierarchy of precedence so an explicit permission always overrides an inherited one, whether it is denied or allowed.

Since permissions in CES only support denied and allowed entries, a denied entry always overrides an allowed entry for a user or a group, with no regard to whether the allowed permission was inherited or explicitly set. For that reason, when group permissions are used in Jive, in some cases these groups have to be expanded and permissions have to be set on group members to make sure CES permissions mirror those from Jive.

Example: Consider the following situation.

Group A contains three members: member 1, member 2 and member 3.

For a given Jive community, Group A is denied the View Documents permission through an inherited permission but member 1 is explicitly allowed the View Document permission.

When you look at the final permissions in CES, you see that member 1 is effectively allowed on any document from that community and that member 2 and member 3 are denied. There will be no denied permission set on Group A since doing so would deny all members from the group, including member 1.

Therefore, expanding groups and setting permissions on group members rather than on the groups themselves is not effective in CES until a refresh operation is performed.

Incremental Refresh

Incremental refresh is not detecting modifications made to Jive permissions

Modifications made to permissions in Jive do not impact the last modification date of objects affected by the permission modification. Since incremental refresh is using this last modification date to retrieve objects to update, the permission modification is not detected.

When Jive permissions are frequently modified, schedule a source refresh weekly or more often to keep the index permissions synchronized with Jive permissions.

Incremental refresh is not detecting new users added to the Jive server

The Jive 5/SBS/Clearspace connector keeps a local cache of all active Jive users for faster access and to improve indexing performances. New Jive users are detected by incremental refresh and added to CES only when this local cache of users expires and is refreshed.

By default, the user cache is refreshed every 24 hours but can be refreshed more often by adding the UserCacheLifeSpan parameter to your source and setting its value (in minutes) accordingly (see Modifying Hidden Jive 5/SBS/Clearspace Source Parameters).

Note: The UserCacheLifeSpan parameter is also available on the security provider and its value should always match the value set on its associated source (see Configuring a Jive 5/SBS/Clearspace Security Provider). If a security provider is used by more than one source, make sure the UserCacheLifeSpan parameter on the security provider matches the lowest value of this parameter among all its associated sources.

Incremental refresh is not retrieving items that were deleted more than two weeks ago

The connector needs to keep track of items that were deleted from Jive in order for incremental refresh to keep the index up-to-date. Every time a incremental refresh run completes, items that were deleted more than two weeks ago are removed from the deleted history.

If incremental refresh was disabled on a source for a period greater than two weeks and you have more than one source performing incremental refresh on the same Jive server, you should perform a source refresh on the source where incremental refresh was disabled to make sure your index is fully up-to-date.

Secure Addresses

When clicking on search results within a CES search page, you are taken to a secure Jive connection (e.g.: https://JiveSite:8443/docs/DOC-1001) even though the starting address specified on the source is not (e.g.: http://JiveSite:8080)

If the web server hosting Jive is configured so that SSL is enabled for Jive, you should always use the secure starting address.

Error during Refresh or Rebuild

When refreshing or rebuilding a Jive source, the following error is displayed and the operation is aborted:

Jive Error: Client found response content type of 'text/html;charset=ISO-8859-1', but expected 'text/xml'. The request failed with the error message:--<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><title>System Error</title> <style> body { font-family : arial, helvetica, sans-serif; font-size: 81.25%;} td, th, p, div, span, li, a { font-size : 1em; } h1 { font-size : 1.72em; } code { font-family : courier new, monospace;font-size : .8em;}} </style></head><body><div id="jive-header" class="jive-clearfix"> <h1>System Error</h1></div><p>We're sorry but a serious error has occurred in the system.</body></html>--

This is the typical error message returned by Jive when an internal error occurs on the Jive server. While there is not much that you can do to prevent these errors from occurring, it is recommended to restart the Jive service if the errors occur frequently.

When refreshing or rebuilding a Jive source, the following error is displayed and the operation is aborted:

Jive Error: PermGen space.

A PermGen related error means the Jive server was temporarily out of memory. If this error occurs repeatedly, ensure your Jive JVM settings follow the recommendation and, if required, increase the PermGen Heap space to at least 512 MB (see the Jive document Adjusting the Java Virtual Machine (JVM) Settings).

People who viewed this topic also viewed