Salesforce

Configuring Servers and Projects to Start Automatically (Magic xpa 3.x)

Printable View
« Go Back

Information

 
Created ByKnowledge Migration User
Approval Process StatusPublished
Objective
Description

Configuring Servers and Projects to Start Automatically (Automatic Provisioning) (Magic xpa 3.x)

When the Magic Space is deployed, the Grid Service Agent (GSA) automatically loads Magic servers to serve projects defined in the projectsStartup.xml file in the GigaSpaces-xpa\config folder. You will need to update this file with the Magic projects and servers’ details. In this file, any declaration at the Server level will override the declaration at the project level.

Recommendation: Place the projectsStartup.xml in a shared network location and set GigaSpaces-xpa\bin\setenv.bat in all of the cluster’s machines to access the same file. For example: set PROJECTS_STARTUP_XML=\\MyServer\config\projectsStartup.xml.

Note:

  • Different projectsStartup.xml files can be used across the grid – during startup by the StartProjects.bat file and by the GigaSpaces Monitor.

  • You can define repetitive values once in the CMDLineArgs attribute (optional) in the Projects element. For example: <Projects CMDLineArgs="/InternetDispatcherPath=/MagicScripts/MGWebRequester.dll /LicenseName=MGENT1 /MaxConcurrentUsers=100 /MaxConcurrentRequests=10">

  • When starting projects using the GS-agent (from the projectsStartup.xml file), the project name is automatically taken from the ApplicationPublicName environment setting.

When the space is deployed on multiple servers, you should:

  1. Configure the GSA in all of the servers to deploy the space and start the Magic xpa servers. This is done in the gs-agent.bat file, found in the GigaSpaces-xpa\bin folder as follows: gsa.deployAndStartProjects 1

  2. Start two local LUSs (LookUp Services) and two global GSMs (Grid Service Managers):

    a. In two pre-selected machines, set gsa.lus 1 in the gs-agent.bat file.

    b. In each machine in which a GSA is started, set gsa.global.gsm 2.

    For an explanation about local and global setup refer to GigaSpaces's documentation by going to Home > Administration > Runtime Configuration For example (GigaSpaces V10.1): http://docs.gigaspaces.com/xap101adm/runtime-configuration.html.

  1. In the setenv.bat file, found in the GigaSpaces-xpa\bin folder, set: XAP_LOOKUP_LOCATORS=host1,host2 (where host 1 and host 2 are the two machines where the LUSs were started).

    This setup should be applied in the setenv.bat file of each machine in which a GSA is started.

  1. Similarly, in each Web requester's Mgreq.ini file (found in Scripts\config), set LookupLocators=host1,host2.

  2. Similarly, in the GS monitor, set host1,host2 in the Connection details.

  3. It is recommended that you refer to the Log Files and Unknown Errors topic for an explanation on directing all log files to a central location.

Space Startup Sequence

The startup sequence of the grid is as follows:

  1. The GSA is started (usually as a service) on each application server that is part of the grid. The Grid Service Agent starts the core grid infrastructure to connect all application servers together.

  2. The first GSA deploys the Magic Space and starts the projects. This Space contains all Magic-related objects that are shared across the grid.

  3. The same GSA also deploys the projectsStartup.xml information into the Magic Space to enable projects to start automatically.

  4. All GSAs in the grid load the Magic xpa servers as defined.

Example ProjectsStartup.xml File

The following example of a projectsStartup.xml file defines a start-up configuration of the test application GigaSpaces-xpa\test\GSTest.ecf:

This example file configures the following settings:

  1. The application will be started on two server machines: Server1 and Server2.

  2. Server1 will start two Magic xpa servers (engines), each with ten worker threads.

  3. Server2 will start one Magic xpa server (engine) immediately and another on demand (if all other engines will be busy), each with five worker threads. Each engine will be limited to 200 contexts.

Note:

  • You can have each server start a different application (<StartApplication> in the <Server level). However, it is recommended to use the same application for all of the servers, from a shared location, as shown in the <Project element.

  • To use an @ini file with a space in its names, wrap the file name with single quotes.

Reference
Attachment 
Attachment