Salesforce

Server Troubleshooting (Magic xpi 4.5)

« Go Back

Information

 
Created ByKnowledge Migration User
Approval Process StatusPublished
Objective
Description

Server Troubleshooting (Magic xpi 4.5)

Q1

Why won't the Server start?

A1

If the Server does not start, you should check the following:

  • Your license's type.

  • The actual license that Magic xpi is searching for in your project's ifs.ini, which is in your installation.

Verify that these are the same by checking the [MAGIC_ENV]LicenseName= <Server license name> flag. If the name of the license in the ifs.ini file does not match your license, you should change the license type in both the main ifs.ini and in the existing projects. This ensures that every new project that you create uses the correct license type.

  • If the project was built in the Debug mode and you are trying to run it in the Server.

If you are using non-English characters in your project, see Language Support to make sure that your machine is set up properly.

Make sure to execute the Rebuild Solution procedure again.

Q2

I'm working with IIS7. Why doesn't the HTTP Trigger work?

A2

There are certain settings that need to be made when working with Magic xpi and IIS 7. For more information, see the Working with Magic xpi and IIS 7 technical note.

Q3

Why doesn't the Magic xpi Studio work on Windows 2008?

A3

Permission problems are encountered when running Magic xpi on Windows 2008. When the Magic xpi Studio opens, the following error is generated:

"Failed to open: MAGIC.INI"

In addition, when attempting to create a resource or a service, the following error is generated:

"Unable to lock the resource: DefinitionProperty"

The same problem also occurs when trying to run the Migration utility. An error similar to this one is generated:

"Unable to lock the data source: DataType Record"

There are two ways to solve this problem:

  • Right-click on the shortcuts, and run the Studio as an administrator.

  • Remove the UAC component if it is not in use.

For additional information, see the following topic:

Q4

When starting the Magic xpi Server, I get a Windows message saying that the process could not access the memory. After clicking OK, the Magic xpi Server goes down and the following error appears in the log: "Security file could not be openedSecurity file could not be openedAppserver shutdown". Why is this?

A4

This error, which only appears when starting the project as an executable, indicates a problem with the usr_std.eng file that is located in the \Support folder. Replace the file with a file from another installation of the same version.

Q5

Why am I getting an HTTP status 413 error?

A5

This error is a result of a size limitation for IIS. IIS is limited, by default, to receive requests with a size of up to 48K. Change the maxRequestEntityAllowed and uploadReadAheadSize metabase properties to a number smaller than 48K.

For example:

C:\Windows\System32\inetsrv>appcmd set config -section:asp -limits.maxRequestEntityAllowed:1000000

Applied configuration changes to section "system.webServer/asp" for "MACHINE/WEBROOT/APPHOST" at configuration commit path "MACHINE/WEBROOT/APPHOST"

C:\Windows\System32\inetsrv>appcmd.exe set config -section:system.webServer/serverRuntime /uploadReadAheadSize:1000000

Applied configuration changes to section "system.webServer/serverRuntime" for "MACHINE/WEBROOT/APPHOST" at configuration commit path "MACHINE/WEBROOT/APPHOST"

Q6

Although I increased the number of workers for an existing deployment, the number of processed requests remains the same. Why is this?

A6

This issue can occur due to locking between the threads within the process. There are several possible solutions to this:

  1. Check the SpecialEventQSizeLimit flag in the ifs.ini file. This flag determines the number of requests that wait in the activity thread until they are handled. Any other request that cannot enter that thread’s queue remains in its original flow worker until it is handled. That worker waits until the request enters the activity thread queue, and this waiting period is what causes the performance problem described above to occur. The SpecialEventQSizeLimit flag is general per server, and is not worker-related. Therefore, no matter how many flow workers are running, the queue will be determined by the value set in this flag. If you increase the flag’s value, there will no longer be a bottleneck in the queue due to its size. (Although there might be a bottleneck for other reasons.) Nevertheless, you should take into account that if this number is very high and many workers send activity log messages simultaneously, the queue can be full. This can put a heavy strain on the memory, and can therefore significantly hurt performance. Also, activity log messages with big payloads can also negatively affect performance (see the ActivityBlobFileLocation and ActivityBlobFileFallbackToDB flags). As you can see, there is a trade-off involved, and you should determine what the preferable value for this flag is. The default value is 5000. In any case, the best practice is to reduce the unnecessary activity log messages by limiting information that is written to the internal database, such as statistics collection and the level of activities that are logged. This will improve the Magic xpi Server throughput.

  2. Check the flow’s Max Instances property.

  3. If your project is using a Locking utility, make sure that it does not enter a deadlock scenario.

  4. Check you have enough threads in your license file.

Reference
Attachment 
Attachment