FAQ

The default session timeout of a Muse Proxy Application is of 30 minutes. When the authentication session of the Muse Proxy Application is close to end, a Session Timeout warning pop-up and/or a Session Timeout warning window will appear. Each of them displays a message which notifies the user regarding the remaining time from the current authentication session. The time when the warning pop-up and / or a Session Timeout warning window will appear is configurable using the AUTHENTICATION_TIMEOUT_ALERT_WINDOW_DURATION field for the Application Web Module from the ${WEB_CONTEXT_HOME}/WEB-INF/web.xml configuration file. By default, this is set to 60 seconds before the Muse Proxy application session will end. The Muse Proxy Application interface is on top of other core layers, hence increasing the interface timeout value involves increasing the underlying timeouts to avoid the expiration of system sessions before the interface. The underlying timeout values must be bigger than the interface value, or at most equal. For example, to increase the application inactivity timeout to 60 minutes, the following must be done:

Increase timeout values at the system level

1. ${MUSE_HOME}/proxy/modules/handlers/RequestHandlerWeb.xml Edit this file on disk and change the value of CLIENT_SESSION_TIMEOUT to 3900000 . The default value is: (35 minutes) The new value: 3900000 (65 minutes)
2. ${MUSE_HOME}/proxy/webcontexts/NavigationManager/profiles/NavigationSession.xml Edit this file on disk and change the value of NAVIGATION_SESSION_TIMEOUT to 3600000 . The default value is: 1800000 (30 minutes) The new value: 3600000 (60 minutes)
3. ${MUSE_HOME}/proxy/webcontexts/NavigationManager/profiles/filters/MuseProxyAuthenticationToken.xml Edit this file on disk and change the value of AUTHENTICATION_TOKEN_TIMEOUT to 7200000 . The default value is: 3600000 (60 minutes) The new value: 7200000 (120 minutes) The value of AUTHENTICATION_TOKEN_TIMEOUT must be significantly higher than the NAVIGATION_SESSION_TIMEOUT.

For the new system timeout values to be considered, the Muse Proxy service must be restarted.

Increase the timeout value at the application level

  ${MUSE_HOME}/proxy/webcontexts/Applications/APPLICATION_ID/WEB-INF/web.xml This file can be edited in the Muse Proxy Administrator Console, Applications -> Manage Applications, hover the desire proxy application and click the WEB.xml button. Locate the AUTHENTICATION_TIMEOUT field and change its value from the default 1800000 (30 minutes) to 3600000 (60 minutes) To load the new value immediately, go to the Advanced -> Operations menu and click the Refresh Applications button.

There are three inactivity timeouts levels in Muse. In ascending order they are:

– application level

– WebBridge level

– ICE level

So the application times out before the WebBridge which times out before ICE. This means that values for the timeout levels must go in ascending order too where ICE is longest and application is shortest. Getting this wrong can mean that the WebBridge or ICE session could expire before the application session expires. In that case a user can still access application features but searches will fail because there is no WebBridge session (the application’s path to ICE) or no ICE session (ICE performs the search and returns results to the application).

Default values for these levels are as follows:

– application level15 minutes

– WebBridge level20 minutes

– ICE level30 minutes

To set each of the above timeouts, the user have to:

a) for application timeout: access the applciation settings via MCAA console (Application General Settings>Interface Options>Logoff) and set the “Session Timeout” value as needed. Changes here affect only the application you’re editing.

b) for WebBridge timeout: edit the file $MUSE_HOME/web/MusePeer.xml and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in seconds. Http server restart is necessary to load this value. Changes here affect all applications using the Muse WebBridge.

c) for ICE level: edit the file $MUSE_HOME/use/ice/ICECore.xml and modify the MAX_INACTIVE_INTERVAL tag. Values of this tag are specified in milliseconds. ICE server restart is necessary to load this value. Changes here affect the application on the installation.

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?

There are two parameters involved here:

• CONNECT_TIME_OUT: specifies the timeout value, in milliseconds, to be used when opening the communication link for each resource (e.g. URL) used by this source.
• READ_TIME_OUT: specifies the timeout value, in milliseconds, that is involved upon reading on the communication channels.

One can increase the timeout for a given Source Package by increasing the value in the CONNECT_TIME_OUT and READ_TIME_OUT fields (the entry is in milliseconds; 1,000 milliseconds = 1 second). To edit these fields of the source profile one must use the Muse Source Console:

• login into the Muse Source Console
• select the desired application from the list of applications
• go to the “Configure” tab
• click on the “Modify” button for the desired source
• update the “Connect Time Out” and “Read Time Out” inputs with the desired values
• to submit the modifications click on the “Update” button

Note: The values for the “Connect Time Out” and “Read Time Out” fields must be given in milliseconds.