FAQ

The first step to try to resolve this issue is to update the Source(s) in question. If the installation date and status information still does not display after the Source(s) are updated, it is possible that the XML database is corrupted. Use our backup & restore utility to recover from this problem. This procedure is detailed under the XMLDB category.

Not seeing the SPs related data, as status, version, install and build dates, can point an issue with the Local InfoBase.

The most comon issues that have these results are:

1) XMLDB corruption

For more information about this, please see the “How do I perform a backup/restore operation of the XML database?” (1019) FAQ.

2) InfoBase Bridge not started due to a port conflict

Muse InfoBase Bridge is using the 8005 port, so please check the Embedded Apache Tomcat logs to see if there are any entries of the form (which point a conflict):

Address already in use: JVM_Bind:8005

This port can cause a conflict if on the machine there is an external Apache Tomcat (or other software) running and listening on this port. In case of Apache Tomcat, the 8005 port is used for shutdown and it is configured in the $TOMCAT_HOME/conf/server.xml. For other servers, please consult their documentation.

The advice is to change the port of external Apache Tomcat or any other software (not Muse) to something else, eg: 8115, and restart that server and Embedded Apache Tomcat.

If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.

First check the following:
– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.
– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).
– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.
In cases where the target site is working but the communication is slow for some reason the solution is to increase the values specified in the profile of each relevant Source. The value defines the period, in milliseconds, that is allowed for reading on the communication channels before the communication times out. A significant increase (for example, raising the standard value of 60000 to 600000) should overcome this problem. Some experimentation and fine-tuning may be necessary in reaching the optimal balance of network usage.
If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See FAQ “Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?”
If all Sources work within a Muse application individually but some fail when they are searched together, this is an indication that the target site(s) and/or your Internet connection might be slow or under stress conditions.First check the following:

– Is the Internet connection slow? Check independently (outside of Muse) to see if the network is generally slow. If so, increase the timeout for all Sources (see below), or possibly limit the number of Sources users search simultaneously to conserve bandwidth or relieve Source overloading issues.

– Do the same Source Packages always timeout no matter how many other Sources are searched simultaneously? In this case it is likely that the Source site is the problem rather than the network. Increase the timeout only for those Sources (see below).

– Does the machine running Muse have a high load? Stop unnecessary processes and/or increase the memory allocated to Muse servers. Check the “Search Details” (or “+” button) if it is available on the search page and look at the information icon for each failed source to see the cause of the failure. This will be useful in diagnosing where the problem lies.

In cases where the target site is working but the communication is slow for some reason the solution is to increase the value specified in the profile of each relevant Source. The value defines the period, in milliseconds, that is allowed for reading on the communication channels before the communication times out. A significant increase (for example, raising the standard value of 60000 to 600000) should overcome this problem. Some experimentation and fine-tuning may be necessary in reaching the optimal balance of network usage. See I often get “timeout” messages from a Source. When performing a search in the native site it takes around 3 minutes to receive results. How do I increase the timeout of a Source? for even more details on this.

If you experience this problem only in only the Muse Admin Console (where a source works when tested individually but fails when tested in a group with others). You may have a different issue. See Why do some Sources fail when tested in a group in the Admin Console but they work when tested individually?