FAQ

Most Popular

Load More

Latest

Updating a Source Package installed in a Muse Application or adding a new one make use of the Global InfoBase service. The access to the Global InfoBase service is done with a username/password combination that were assigned to you by MuseGlobal. The fact that you get “Source package decode error” messages when updating Muse Source Packages in the Muse Administration Console shows that you did not configure in your Muse installation the username/password for accessing the Global Source Factory service. There are 2 ways for configuring the access details for the Global Source Factory service in a Muse installation:
  1. At the Muse system level. This means that you configure the username/password for accessing the Global Source Factory service at the system level and all administrative users like mcaa and mccs make use of it. To do this setting edit the ${MUSE_HOME}/factory/SourceFactory.xml file and fill in the GLOBAL_IB_USERand GLOBAL_IB_PASSWORD fields with the username/password that were provided to you by MuseGlobal. You should have there the startersf default restrictive details, just replace them with the ones provided to you. A restart of the Muse Embedded Tomcat server is required for this setting to take effect.
  2. At the administrative user level. This means that you can configure the username/password for accessing the Global InfoBase service individually, for each Muse Administration user (like mcaa, mccs). The advantage of this configuration is that you can specify different access details for the Global InfoBase service for each Muse Administration user. Another advantage is that the restart of the Muse Embedded Tomcat server is no longer required. Specifying the access details for the Global InfoBase service for a Muse Administration user is done through the Muse Console for Applications Administration interface (mcaa user) as follows:
    • login into the Muse Console for Applications Administration interface as the mcaa user.
    • go to the Users tab, locate the desired administration user, select it and click on the "Edit Properties" leftmenu item.
    • in the "Edit MAB User Properties" panel fill in the "Global InfoBase User Name" and "Global InfoBase User Password" fields with the appropriate values.
    • re-login into the Muse Administration Console if the setting was done for the mcaa user or login with the user for which the Global InfoBase details were updated.

The “Login error: Maximum number of sessions for user … has been reached. Please try again later.” occurs when the application or system level limit on the number of simultaneous users is reached.

Limits are built in by default as a protection against one single application logging in so many users that it occupies all the resources of the host server and other application users are effectively denied access. Under normal circumstances the limits can be set appropriately for the expected user population and available server resources (see below) so this error should not occur. But in the case of a software problem or some kind of robot targeting the application this is a useful line of protection.

Note that Muse allows administrators to set these logon limits at both the application and system levels.

These setting are kept in the MAX_USER_CONCURRENT_SESSIONS variable, which can be modified as follows:
– system wide level: edit the $MUSE_HOME/use/ice/ICECore.xml file and change the value of the MAX_USER_CONCURRENT_SESSIONS tag.
– application level ($APPLICATION_HOME/profile.xml): access the application settings via MCAA console (Application Actions > Edit Configuration Options) and set the “User Concurrent Sessions” value as needed. Changes here affect only the application you’re editing.

Note: please be aware that low values can deny access too often while high values can allow unmanageable load on the server. We recommend multiple, small adjustments rather than a single large change.

When unistall Muse Proxy 3101 or Muse 2700 (and any interanl 2601,2602, 2603) on a common installation of both of them on some machines the following error is obtained:

Errors occurred during the uninstallation.

com.installshield.product.service.registry.LoggedSoftwareObject cannot be cast to com.installshield.product.ProductBean

This seems to be related to having components with the same UIDs (using two or more Assemblies (in a dynamic installer) where some features and components had the same key (UUID)).

The workaround to solve this problem is:
1) Go to the folder
C:\Program Files\Common Files\InstallShield\Universal\common\Gen1
2) Delete the entire folder named “_vpddb”
3) Restart the uninstallation.

See: [http://cdac.in/index.aspx?id=hi_hs_HL7Tutorial#Uninstallation instructions for SDK for HL7 Java Edition(Windows/Linux/Mac)]

When one or more new IPs are added to a machine running Muse ICE, ICE will not start again until the Muse product is re-registered. Running the Muse Registration process ensures that all the current IPs of the machine are added to the serial.properties file, which is required for the Muse ICE server to start successfully.

For more details about the Muse Resistration procedure, please see the "$MUSE_HOME/doc/Muse Install.pdf" document, the “Product Registration” and “Running the Muse Registration Setup” chapters.

This a known/intermittent behavior of some old browsers, like Internet Explorer 6.

By default, Muse HTTP Server closes client sockets as soon as it finishes sending out the response, in order to recycle sockets as soon as possible. However, there are some problems with certain browsers (like IE6) that send data after the socket was closed by the server. Since the socket was already closed by the server, the browser displays the “The page cannot be displayed” error instantly.

To work around this, Muse Http Server was adapted to wait a configurable amount of time after sending all the data back to the browser and before closing the socket. This amount of time is configurable through thesocketCloseDelay parameter for the desired Connector in ${MUSE_HOME}/http/conf/contexts.xml file. The value for socketCloseDelay parameter is specified in milliseconds.

Note: This value represents the time that the server waits before closing down the socket to the client. Setting a too high value for this parameter can degrade performance of the Muse Http Server. In general, this value should never be set higher than 100 milliseconds.

To activate the socket close delay for Muse HTTP Server please follow the next steps:

1. Stop the Muse HTTP Server;
2. Edit the "${MUSE_HOME}/http/conf/contexts.xml" file and add the following line:

after the lines (port 8000 below can be any port that Muse HTTP Server was set to run on):



3. start the Muse HTTP Server.

If the problem still persists, a tunning is necessary till a proper value is found (please consider the note above):
1. Shutdown the Muse HTTP Server;
2. Change the value of the “socketCloseDelay” parameter;
3. Start the Muse HTTP Server;
4. Run new tests.

Categories: Muse Search, Sources

Load More