Space Troubleshooting (Magic xpi 4.6)

« Go Back


Created ByKnowledge Migration User
Approval Process StatusPublished

Space Troubleshooting (Magic xpi 4.6)


Why is GigaSpaces not working?


GigaSpaces will not work if the installation path contains the string: (x86), such as: C:\Program Files (x86).


How can I fix memory allocation errors?


From Magic xpi 4.x, any data from triggers and any data sent to parallel or stand alone branches goes through the Magic Space. This means that the default memory allocation settings may not be enough if a very large amount of content is sent, or if external triggers such as HTTP are being used.

The memory allocation settings for the various GigaSpaces entities can be found in the following location: <Magic xpi installation>\Runtime\GigaSpaces\bin\magicxpi-gs-agent.bat.

The Grid Service Container (GSC) that holds the data in the Space is currently configured to 256MB. If you encounter any memory allocation errors, you should consider allocating at least 512MB to the GSC by changing the following line:

set GSC_JAVA_OPTIONS=-Xmx256m -Dcom.magicsoftware.ibolt.home="%MAGIC_XPI_HOME%"


set GSC_JAVA_OPTIONS=-Xmx512m -Dcom.magicsoftware.ibolt.home="%MAGIC_XPI_HOME%"


Why didn't the MAGIC_INFO space (mginfo) and MGMirror processing unit deploy successfully?


In the GigaSpaces Management Center, you might see errors under the GSC object. For example:

“ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] - Cannot create PoolableConnectionFactory (The TCP/IP connection to the host ORGAT-7-LP, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall.".)”

If you get this error, you will not be able to debug or run the project.

To solve this issue, set the MSSQLSERVER protocol's TCP Port to 1433.


What can I do if the grid did not start properly?


If the grid started properly, you should see a grid listed in the Hosts tab and the grid components with the Lookup Locator defined during the installation.

However, you may encounter one of the following issues:

  • You will not see the grid listed in the Hosts tab. In the example above, you wouldn’t see debbies-7. This means that the grid did not deploy.

  • You will not see the gsa, gsc, gsm, and lus entries under the grid name. This means that one or more of the grid components did not load properly.

Note: The first thing you should do when the grid is not working properly is to check that the LOOKUPLOCATORS value in the magicxpi-setenv.bat file is set correctly.

If you encounter one of these issues, you can also check the following:

  • Try stopping the Magic xpi GSA service, waiting for all grid processes (if they exist) to terminate, and restarting the Magic xpi GSA service.

  • If you did not select the Install the Grid Service Agent (GSA) as a service check box during installation, the grid will not deploy. Run the Install_GSA_service.bat file from OS_Service\scripts to install the GSA. With some operating systems, such as Windows 7 and above, you need to run this command using administrator credentials.

  • If you did not select the Run the LUS check box during installation, the grid will not deploy. Define gsa.lus 1in the magicxpi-gs-agent.bat file.

  • Click on one of the running components and you will see the log for that component. Any errors will be seen in the log, as shown in the image below:

  • For all of the application servers, if your machine is running multiple network interfaces, make sure that the NIC_ADDR value (in the <Magic xpi installation>\Runtime\GigaSpaces\bin\magicxpi-setenv.bat file) is set to hold either the IP assigned to the network card or the name of the network card itself. Then, add the NIC_ADDR value to the Magic.ini file’s jvm_args section:

    -Djava.rmi.server.hostname=<your network card IP address here>

    Note: The host name or IP address should not be surrounded by quotation marks.

  • When working in a clustered environment, if the grid entities are not available in the GigaSpaces UI, check that the firewall is not blocking the ports used by GigaSpaces. There are two settings that control the ports:

    • The Discovery port, which should be opened in the firewall.

    • The range of LRMI ports, which should be set to a fixed range and also opened in the firewall.

Additional information about the ports can be found here.


How do I make sure that GigaSpaces does not use up too much memory on my development machine?


Currently, the default memory and clustering settings are configured for a production machine. In a development machine, the settings can be changed to decrease the application’s footprint.

The recommended settings for the <Magic xpi installation>\Runtime\GigaSpaces\bin\magicxpi-gs-agent.bat file are:



set GSC_JAVA_OPTIONS=-Xmx256m -Dcom.magicsoftware.ibolt.home="%MAGIC_XPI_HOME%"



In the line starting with call gs-agent.bat, set gsa.gsc to 1 instead of 2.

For example:

call gs-agent.bat gsa.gsc 1 1 1 gsa.mgmirror 1 gsa.mgdeploy 1 gsa.mginfo 1

Clustering is defined in the <Magic xpi installation>\Runtime\Config\magicxpi_sla.xml file.

By default, the Space is defined with two partitions and a backup for each partition. For a development machine, a single partition should be enough and the backup is therefore not required.

Use the following as the content of the magicxpi_sla.xml file:

<beans xmlns="" xmlns:xsi="" xmlns:os-sla="" xsi:schemaLocation="">

<os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="1" number-of-backups="0" max-instances-per-vm="1">



To see our video demonstration about reducing the memory usage on development machines, click here.


Why can't I see a server in the Monitor?


After starting a server from the Monitor or from the Start link, the server entry must appear in the Monitor. If it does not appear, then no server entity (ServerData object) was created. To see why there was a problem creating an entity in the Magic Space or accessing the grid, check the mgxpicmdl.log file on the machine where you requested the operation, and not on the remote machine.


Why does the server's status remain as START_REQUESTED?


After selecting Start from the link or from the Monitor, you initially receive a START_REQUESTED status.

This is a temporary status and you expect that the status will change to RUNNING.

In the image above, the host machine (SPACECOURSEWIN7) has a status of START_REQUESTED and did not receive a Process ID, which you can see in the Process ID column where the value is set to null. To try and figure out why this happened, you need to find the relevant log. Remember that all logs have the name of the log and the process ID number:

  1. In the <Magic xpi installation>\Runtime\logs and <Magic xpi installation>\Runtime\logs\java folders, try to delete all of the logs. The logs that you cannot delete are the ones currently being accessed by processes. These logs are the ones that you want to have a look it.

  2. Load the GigaSpaces UI by clicking the link on the desktop or via the Start menu.

  3. Look for the PID of the primary Grid Service Container (GSC), as in the image below. In this case, the Process ID is 2312.

  4. Open the log: magicxpi_<PID>.log located in the <Magic xpi installation>\Runtime\logs\java folder (in this example, magicxpi_2312.log). You will notice that the Magic processing unit did not find the Grid Service Agent (GSA) on the host machine:

There are a number of reasons that this may happen, such as:

  • This scenario may be valid, since you may have decided that the host machine will only be available at peak hours. In this case, you can simply wait until the machine becomes available.

  • There is a problem with the host machine.

  • There is a problem with network access to that machine. In other words, the machine is not available.

  • There is a problem with the naming. The names of the host in the start.xml file may not match the name seen by the grid because of Domain Name System (DNS) resolution. Use the IP address of the machine instead of the name in the start.xml file to solve this issue.


Why is the server's status START_IN_PROGRESS?


In this scenario, the Magic processing unit has found the remote computer, and the GSA has managed to run the Magic xpi server with the parameters. The Magic processing unit updates the server status with START_IN_PROGRESS.

After an internal timeout that involves a number of checks to see if the serverdata entity’s status is still START_IN_PROGRESS, the Magic xpi server could not connect to the Magic Space and the Magic processing unit then updates the server’s status as START_FAILED.

When the status becomes START_FAILED, the Magic processing unit checks with the GSA whether there is a handle for the Magic xpi server process. It is quite possible that there is a process, which is a so-called phantom process as it is not handling any projects. If there is a handle, the Magic processing unit instructs the GSA to kill the process.

There are a number of reasons that this might happen, such as:

  • A license problem.

  • One of the parameters in the command line is incorrect, such as the project name or path.

  • The user does not have access to the shared drive where the project exists. The Magic processing unit requests that the GSA on a remote machine load the Magic xpi server. Therefore, the Magic xpi server loads with the permissions of the GSA and not necessarily the permissions of the current user. The current user may have access to the project on the shared folder, as well as the license, but the user assigned to the GSA process may not have such access.

The errors above may appear in the ifs.log file. It is good practice to check in the ifs.log file for relevant errors.

Note: The following are indications that there is a permission issue in accessing the project’s folder:

  • You do not have an ifs.log file.

  • In the Windows Task Manager, the MgxpiServer.exe process consumes a small amount of memory (about 18MB).


Why does the server's status become SERVER_INITIALIZING?


This is a temporary status in which the GSA has managed to run the Magic xpi server. The Magic xpi server updates the server status as SERVER_INITIALIZING.

The Magic processing unit checks the server status to see if it has been updated to RUNNING. If it is not RUNNING, then after an internal timeout the Magic processing unit will update the server’s status to START_FAILED.

In some cases, this means that the actual Magic xpi server application and the project metadata were not loaded into the Magic xpi process. In other cases, such as database connectivity issues, this means that the project was created in the Space, but the engine will terminate later because of the database issue.

This occurs when the Magic xpi server could not access the database:

  • Open the <Magic xpi installation directory>\Runtime\logs folder on the machine registered in the start.xml, and look for the log for the project.

  • Open the log and see if there is an error there. If there was no access to the database, you might see an error such as: Failed to open, data source: ifs_ods


What should I do if when starting the GSA service I am getting the following error in then log (or when running the magicxpi-gs-agent.bat script from the command line): “Could not find or load main class xpi”?


Magic xpi requires 8dot3name (short name) support when it is installed in a location that contains spaces.

Make sure that 8dot3name is supported. You do this by opening a command prompt as an administrator, and running the following command:

fsutil 8dot3name query <required installation drive>

For example, if you intend to install Magic xpi on the C drive, use this command:

fsutil 8dot3name query c:

The fsutil utility is located under C:\Windows\system32. If the above command is not found, navigate first in the command prompt to your system32 folder.

If the result of the command is that the volume state is 0 (8dot3 name creation is enabled), and the registry state is 2, the default (Volume level setting), then 8dot3name is enabled and you can continue with the installation.

If 8dot3name is not enabled, you should run the following command as an administrator:

fsutil 8dot3name set <required installation drive> 0

For example, to enable 8dot3name on the C drive:

fsutil 8dot3name set c: 0

You may need to restart your computer for the settings to take effect.


Why isn't my space deploying properly when using Windows authentication with my internal database?


This might be a Magic xpi configuration issue or a system permission issue.

1. Magic xpi configuration issue

After the installation, if you want Magic xpi to connect to the internal database with Windows authentication, you have to make changes in the datasource.xml file. This file is located at: <Magic xpi installation>\Runtime\config.

  1. Remove the username and password properties. For example, remove the following text: username="magicxpi4_1" password="MagicPass#3".

  2. Add ;integratedSecurity=true to the url property. For example, your file would look something like the text below. The username and password are removed and you would add the red text:


<datasource id="1" hibernate.default_schema="dbo"


hibernate.default_catalog = "magicxpi4_1"




2. System permission issue

This is the Windows security behavior because the NT AUTHORITY\SYSTEM user does not have system administrator permissions in the SQL server, whereas the user login does. In Windows, the OS service is run with the NT AUTHORITY\SYSTEM user as the default. However, if GigaSpaces is started as an agent it runs with the user login instead.

To avoid this problem, you have two options:

  1. Give system administrator permissions to the NT AUTHORITY\SYSTEM user.

  2. Change the user account that runs the GSA service to the user that has the required permissions.