|
|
|
|
[MRB_ENV] section
|
|
|
BrokerPort
|
The ports that the Magic Request Broker listens to and waits for requests from. The Magic Request Broker can listen to a total of 5 consecutive ports starting with the port specified.
Syntax: BrokerPort = port number:
(default number =4000)
|
|
EnginesPriority
|
A list of up to 9 computer names that are used to provide server engines. This list controls the order in which the Magic Request Broker chooses engines to serve client requests. The Engines Priority list operates sequentially so that the engine for the first computer executes the client command, if available, before the engine of the second computer, and so on.
|
|
PasswordSupervisor
|
An optional value that restricts the user’s access to the Magic Request Broker. If specified, security checks will occur during the following broker operations:
-
Clearing or prioritizing any command request in the queue (a user can modify a command request based on the user name and password used when the request was submitted).
-
Terminating the Magic Request Broker.
-
Loading new executables.
-
If PasswordSupervisor is not specified, security validations for user name and password are inactive.
|
|
PasswordQuery
|
An optional value that can be used to restrict access to the Magic Request Broker. If specified, a password is checked before allowing a user to query a request of another user. Any user can access the Query Queue and Log to view their own requests, based on the user name and password entered or in effect when the request was submitted, without any security restrictions. The Magic Request Broker accepts the user name and password of the service, the user name and logon password to the Magic xpi project, or the user name and password stored in the Mgreq.ini file (for cmdl/internet only).
If PasswordQuery is not specified, security validations for user name and password are inactive.
Note: The Query Password is not set up during the installation. It has only limited application, allowing users to query the engine status and running applications.
|
|
Reload
|
When this setting is set to Yes, the Magic Request Broker reloads any instance of a Magic xpi enterprise server that was not terminated by the Magic Request Broker.
Example: Reload=Y
|
|
Log
|
A reference to a file that logs high level Magic Request Broker activities such as initialization, receiving requests, locating enterprise servers, passing enterprise server information to the requester, and so on.
This log can be used to check if a certain request was accepted by the Magic Request Broker and how it was handled.
Syntax: LOG=([Log File Path and Name] [Sync] [Level])
Example: LOG=mrb.log Y C
Log File Path and Name: Any valid name that does not include spaces.
Sync:
Y – The log file opens and closes for each line. This allows for the deletion of the file while the components are still loaded in memory. It also allows the log file to be shared among several modules.
N – The log file opens and closes only during the component initialization and termination operations.
F – Each line designated for printing is sent to the Log file. The Log file only opens and closes during the component initialization and termination operations.
Level:
C – Customer level. The lowest log status.
S – Support level. An intermediate log status.
R – R&D level. The highest log status.
To let the Magic Request Broker log low level activities (such as connect, send, receive, and so on), you can define the log in the Mgreq.ini file located in the Magic Request Broker directory.
|
|
EnableFilters
|
EnableFilters = Y/N
This keyword can be used to disable (=N) or enable (=Y) the filters mechanism.
If the mechanism is disabled, the keywords 'Filters' and 'AllowReserve' have no impact.
The default is N.
|
|
Filters
|
You can use this field to specify how threads are allocated for requests of different filter types, such as HTTP End Users, SOAP, COM, and requests without a filter.
Example: The example below shows you how an enterprise server with a license of 20 threads can be designated to service different types of requests:
The filter string entered for the above example would be:
HTTP_endusers:10%|SOAP_BT:30%|COM_primary:20%
If the accumulated percentage is greater than 100%, the last filter entry that exceeds the accumulated percentage of 100% will be adjusted to be equal to 100% and all subsequent filters will be discarded.
|
|
AllowReserve
|
When the accumulated percentage of designated filters is less than 100%, you can specify Yes (default) to reserve the remaining percentage for other filters.
When AllowReserve = No, only requests without a filter can use the remaining percentage.
|
|
QueueMaxSize
|
By default: no limit. When the broker already has QueueMaxSize requests in its queue, each subsequent request that cannot be served immediately (sync or async) will not enter the queue, and the requester will receive an error.
|
|
ReqHistorySize
|
ReqHistorySize = number
The broker has a history log describing each request that was processed (accessible via mgrqcmdl QUERY=LOG).
This keyword controls the number of requests for which the broker keeps details in its history log.
The default is 20,000 requests. The minimum value is 5,000. The maximum value is 100,000.
|
|
ActivityLog
|
The ActivityLog setting lets you specify the Magic xpi Request Broker log file name and path.
An example of the ActivityLog setting is:
ActivityLog=logs\broker.log
If the Activity log is not set, it is created by default as mrb_event.log.
The Activity Log lists activities, such as:
-
The broker’s startup and shutdown.
-
Instructions to spawn servers (e.g. from the Broker Monitor).
-
Instructions to terminate servers (e.g. from the Broker Monitor).
-
Servers’ startups (while being registered to the broker) and shutdowns.
-
Errors, such as TCP/IP connections reset.
Log format:
Thread ID Current Time,last 5 digits of the time in milliseconds Current Date Message
|
|
LoadBalancing
|
LoadBalancing = Y/N/T
N – The broker will send requests to the engine that has the maximum number of active contexts but have not yet reached the maximum number of concurrent users allowed for the engine.
Y – The broker will send requests to the engine that has the highest priority and least number of active contexts.
T – Distributes the load evenly between runtime engines, according to the percentage of executing threads out of the maximum threads allowed for an engine.
The engine with the lowest percentage value will be selected.
In case of identical percentage values: the engine with the higher maximum thread count will be selected.
The default is Y.
|
|
ServerTimeout
|
The interval duration, in seconds, within which the broker instructs the engines to send an I-AM-ALIVE message during the execution of asynchronous calls.
If the value is 0, then the engine will not send the I-AM-ALIVE message to the Magic Request Broker.
If the engine crashes or is terminated in an abnormal way during task execution, it is understood by the Magic Request Broker as no response from the engine.
Syntax: ServerTimeout = n
|
|
CommTimeout
|
The interval duration, in seconds, that a TCP/IP operation (connect/send/recv) will retry before failing the operation.
This setting in the Mgrb.ini file overrides the setting in the Mgreq.ini file for messages sent by the broker. .
Low-level messages of the generic requester layer still use the setting from the Mgreq.ini file.
The default is 10 seconds. The minimum is 1 second.
|
|
ShutdownTimeout
|
ShutdownTimeout = number
This interval duration is set in seconds, to instruct all enterprise servers to shut down gracefully within the specified duration.
By default (=1), the broker instructs all enterprise servers to shut down immediately, and then shuts itself down immediately.
|
|
TerminateEnginesDuringShutdown
|
TerminateEnginesDuringShutdown=[N]|Y
This setting is only effective if ShutdownTimeout > 0 (otherwise it is ignored).
If the keyword is set to Y, the broker will terminate all runtime engines spawned by that broker. The broker already records the process IDs of all runtime engines. The broker will use the process IDs to kill each runtime engine if it was not shut down gracefully.
|
|
ContextsUsage
|
ContextsUsage = Y/N
When this setting is set to Yes, the MRB will save the contexts usage details into a file. The data will be saved when the context is closed.
This feature is enabled when the Runtime engine's Deployment mode is set to Background. In this case, the context is always the main/only context.
The default is N.
|
|
ContextsUsageLog
|
This keyword allows the controlling of the Contexts Usage output file name.
The value can be relative or absolute.
The default value is ContextsUsage_YYYY_MM_DD.Log.
|
|
FloatingLicense
|
When this is set to Y, servers that are not in the floating license environment mode can then share licenses with servers that are in the floating license environment mode. See also Floating License Support.
The default is N.
|
|
[APPLICATIONS_LIST]
|
This is an optional section containing a list of command line executables or shell commands that can be activated from a remote requester, or upon MRB initialization.
Syntax: APPNAME=<command>,[<work dir>],[<OS username>], [<OS password>],[<number of times to perform upon broker initialization>],[<maximum number of engines supporting the application to launch on demand>]
APPNAME refers to the project name in Magic xpi.
If [OS username] and [OS password] are specified, then the command will use this OS account to start.
If [<number of times to perform upon broker initialization>] is set to 1, then it will load one instance of the declared application.
[<maximum number of engines supporting the application to launch on demand>] – This setting is used to let the MRB load additional enterprise server engines when incoming requests cannot find an available enterprise server. If set, the MRB will load additional enterprise server engines as specified to serve a new request that had no available enterprise server engines (either because all are busy or none are registered in the MRB).
Note: The value of the request parameter, such as -APPNAME= has to match the APPNAME as defined in the [APPLICATIONS_LIST] to have an autoload effect for that engine.
|
|
[REMOTE_APPLICATIONS_LIST]
|
The [REMOTE APPLICATIONS LIST] is an optional section for setting up a multi-computer environment with engines running on computers independent of the Magic Request Broker. An instance of the Magic Request Broker, functioning as a loader, must be active for each computer with engines running on that broker. The local Magic Request Broker automatically connects to the remote Magic Request Broker, specified in the exe entry of this section, and instructs it to load an executable from its list of executables.
The PasswordAdmin must be used if the remote broker has its own password (if not specified, use the password for the local Magic Request Broker).
|
|
[APPLICATION_CLIENTS_MAP]
|
The purpose of the [APPLICATION_CLIENTS_MAP] section is to let you control which server will receive requests from which clients. For example, when several developers are working on the same project file, a developer can check out an object and command the MRB to assign its own engine on the developer's local machine.
This section is used in source controlled environments, in which developers require that requests sent from their machine will be served by a runtime engine running on their machine (in which project resources were checked-out and modified) rather than by other runtime engines.
Note: During the Remote Call execution (when the engine is mapped to this section), the Request Gateway utilizes the logon name and password that are sent with the request. If a user is not logged in to the engine, it is necessary to specify the user name and password from either the Mgreq.ini file for Internet and Command Line requesters, or in the Service repository for the Magic xpi client to view the version of the application related to that logon.
The syntax of this section is:
<Server name 1>:<client name or IP a1>, <client name or IP a2>…,<client name or IP aN>
<Server name 2>:<client name or IP b1>, <client name or IP b2>…,<client name or IP bN>
...
Explanation:
<Server name 1> will receive requests only from <client name or IP a1>, <client name or IP a2>…,<client name or IP aN>
<Server name 2> will receive requests only from <client name or IP b1>, <client name or IP b2>…,<client name or IP bN>
and so on.
|
|
[SNMP] section
| |
|
AverageWaitTime
|
AverageWaitTime = N seconds (default value = 3)
The average time in seconds that a request waits for an available enterprise server. If the average wait time exceeds the AverageWaitTime value, an SNMP trap message is sent to the Network Management Station (NMS).
|
|
AverageProcessTime
|
AverageProcessTime = N seconds (default value = 30)
The average time in seconds for a request to be processed in an enterprise server. The threshold is checked for all registered enterprise servers each time a request is sent. If the average process time exceeds the AverageProcessTime value, a trap message is sent to the NMS.
|
|
DelayThresholdTraps
|
DelayThresholdTraps = N in minutes
The time in minutes that a request of a specified type has to wait between threshold traps to avoid flooding the Network Management Station (NMS). The default value is one minute.
|
