FAQ

Most Popular

Load More

Latest

The following must be done to achieve this functionality: 1. Search the $APPLICATION_HOME/www folder for files containing an HTML form called “logoffForm”. 2. In the files found at #1 add the following in the “logoffForm”: , where app_name is the name of the Application you’re working with. 3. In the $MUSE_HOME/web/www/logon folder create a folder “app_name”, if it doesn’t already exist, where app_name is the name of the Application you’re working with. 4. In the $MUSE_HOME/web/www/logon/app_name folder create a redirect.html file such as the example below: Simply use the URL of the target page you want in place of "http://www.museglobal.com".

1) At the application level:

This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml, field: .
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.

2) At the system level:

In the $ICE_HOME/ICECore.xml file there are 2 fields that control the maximum sessions:

Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.

By default the configured values are:
100
25

This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS value. Also, when changing the value of MAX_CONCURRENT_SESSIONS one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS from applications.

Please Note:

The MAX_USER_CONCURRENT_SESSIONS value set in the $ICE_HOME/ICECore.xml file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.

A new Muse session starts every time you perform a LOGON action through the Bridge. The session is then active until you perform a LOGOFF action or until it times out. You may do multiple SEARCH actions through the Bridge in one LOGON session.

1) At the application level:

This can be done by changing the value of the “User Concurrent Sessions” field from the application’s properties using the Muse Admin Console.
The file from within the application which contains this setting is $APPLICATION_HOME/profile.xml, field: .
Note that this field sets the maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.

2) At the system level:

In the $ICE_HOME/ICECore.xml file there are 2 fields that control the maximum sessions:
Maximum number of simultaneous sessions. New clients are rejected if the number of simultaneous sessions reaches maximum.
Maximum number of simultaneous sessions for one user (application). New connections for the same user are rejected if the number of simultaneous sessions reaches maximum.

By default the configured values are:
100
25

This means that no more than 25 simultaneous sessions are allowed for an user/application and no more than 100 simultaneous sessions for all users/applications. The value of the MAX_USER_CONCURRENT_SESSIONS field must be always smaller or equal with the MAX_CONCURRENT_SESSIONS value. Also, when changing the value of MAX_CONCURRENT_SESSIONS one must be aware that the new value must accommodate enough sessions to cover the largest number of MAX_USER_CONCURRENT_SESSIONS set in the applications. It is not necessary nor recommended for this to be the sum of all MAX_USER_CONCURRENT_SESSIONS from applications.

Please Note:

The MAX_USER_CONCURRENT_SESSIONS value set in the $ICE_HOME/ICECore.xml file is the default one and it is being overwritten by the value from the application level. In other words the value from the application level has the highest priority.

Categories: Muse Search, Sources

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?

Categories: Muse Search, Sources

Load More