FAQ
FAQ by Product
Most Popular
Load More
Latest
- 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.
- 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.