Runtime

Problem

When I validate a Virtual User, it stops on an NL-PLUGIN-ENGINE-03 error.

Solution

Oracle Forms requests that have not been decoded correctly cannot be played back; nor can they be repaired. See the other questions and answers in this section of the documentation and try to identify the problem you are experiencing.

Note: Once a problem has been solved, it is recommended to delete the previous recordings that did not play back correctly.

Problem

I have recorded a simple Oracle Forms scenario. I have not modified the recording and have played it back as is, using Virtual User validation. The option to delete invalid components automatically, described in Oracle Forms during the recording is disabled. The Virtual User fails to execute and an NL-OF-PLUGIN-ENGINE-03 error is returned.

Solution

The Oracle Forms applet can sometimes send requests that contain components that are invalid at the time of recording. The problem can be solved in two ways:

• Manually delete the request DataMessages that reference invalid components.

• Enable the Automatically delete remove invalid components option for the Oracle Forms project and make a new recording.

To delete invalid components manually, follow these steps:

1. Carry out a validation on the Virtual User containing the error in question.

2. Select the request that includes the error. In the Details pane, click on the Response button.

3. Note the handlerId's that are shown between square brackets [ ] and labeled as unknown.

4. Click on the blue Request link to automatically open the request in the library.

5. In the XML content, delete the DataMessages whose handlerId's are reported as being unknown.

6. Re-run the Virtual User validation. Repeat steps 1 to 5 for each request showing the same error.

To delete invalid components automatically, follow these steps:

1. Go to Edit > Preferences > Project settings > Oracle Forms.

2. Check the Automatically remove invalid components check box, then click OK.

3. Repeat the recording of the Oracle Forms application.

4. Run a Virtual User validation and make sure there are no more NL-OF-PLUGIN-ENGINE-03 errors.

Note: The changes are not retroactive, so the previous recordings are not affected. Consequently, if you wish to replay the previous recordings, they will need to be cleaned up by carrying out the procedure for manually deleting invalid components.

Problem

I have recorded a simple Oracle Forms scenario and created a Virtual User that loops a number of Oracle Forms requests over n iterations. The Virtual User fails to execute and returns an NL-OF-PLUGIN-ENGINE-03 error. I noticed that the Virtual User stopped on this error during the 2nd iteration of the loop. The option to delete invalid components automatically, described in Oracle Forms, during the recording is disabled.

Solution

The problem is in the Virtual User design. This indicates that the Virtual User was not in the same graphical state in the Oracle Forms applet in the 2nd iteration as it was in the 1st. At the start of each iteration of the loop, the Virtual User must be in the same graphical state, to the nearest click.

The graphical state of an Oracle Forms applet is defined as a set of graphical components existing at any one time. This example shows a component created in a server response:

<DataMessage> 
  <actionCode>CREATE</actionCode> 
  <handlerId>8</handlerId> 
  <handlerClassId>259</handlerClassId> 
  <properties> 
    <Property> 
      <id>DRAWN_CANVASUSAGE</id> 
      <type>BYTE</type> 
      <value objectClass="byte">3</value> 
    </Property> 
  </properties> 
</DataMessage>

This creates a component with the handlerId 8. The handlerId 8 can now be used in DataMessage in all subsequent requests. When the following message is encountered in a server response:

<DataMessage> 
  <actionCode>DESTROY</actionCode> 
  <handlerId>8</handlerId> 
  <properties/> 
</DataMessage>

The component with the handlerId 8 is destroyed. Requests sent after this response can no longer contain DataMessages that reference the component with the handlerId 8.

Note: It is possible for a handlerId value to be re-used by a completely different type of graphical component later in the recording. These numerical identifiers are uniquely assigned by the server to concurrently occurring components, but may be used by several different components whose lifecycles are disjoint.

Problem

When I validate a Virtual User, it stops on an NL-OF-PLUGIN-ENGINE-01 error. The details reveal an ifError error.

Solution

There are several types of ifError, of which the most common are:

• ifError:3

• The server indicates that the client does not handle cookies. Enable cookie handling for that Virtual User.

• ifError:4

  The server could not create the Oracle Forms process. There is a problem server-side.

• ifError:5

  The server could not start the Oracle Forms process. There is a problem server-side.

• ifError:6

  The server process used to manage the current Oracle Forms session no longer exists. This can happen when the server is subjected to a heavy load or if there is a design flaw in the Virtual User being played back. In the latter case, see Best practices.

• ifError:7

  The server process is currently busy. Re-try the request later. This error indicates that NeoLoad tried sending the request 5 times but did not receive a valid response from the server.

• ifError:11/xxx

  The server is busy, re-try the request in xxx milliseconds. This type of error is handled automatically by NeoLoad and should not appear during the test.

Problem

The Troubleshooting guide has been helpful, but I still need to know more about the way NeoLoad works during recording and runtime.

Solution

The Oracle Forms module may be used in DEBUG mode, which writes even more data to the log files. It can be turned on for debugging a specific use case, but never in a real test runtime.

During the recording, data is written to log files named plugins.log.xxxxx.

During runtime, data is written to log files named loadgenerator.log.xxxxx.

You may quickly access the NeoLoad directory containing the log files by clicking on Help > Open logs folder.

To use the Oracle Forms module in DEBUG mode, follow these steps:

1. Close NeoLoad.

2. Open the <neoload>/conf directory, then open the files logs.xconfig and lglogs.xconfig.

3. Replace the following line:

   Copy

   <category name="neoload.plugins" log-level="ERROR">

4. with this line:

   Copy

   <category name="neoload.plugins" log-level="DEBUG">

5. Re-start NeoLoad. The module is in DEBUG mode for both recording and runtime.

Problem

When a Virtual User executes, I get the following error:

Message: An error occurred while reading the encrypted Oracle Forms response.

Details: Oracle Forms request max retry count reached (5)

Solution

When the server responds with ifError:7/500, NeoLoad reproduces the Oracle Forms applet behavior: by default, it makes a maximum of 5 attempts to send the request to the server and receive a valid response, with a 1000 milliseconds interval between attempts. NeoLoad behavior may be modified by editing the Controller.properties configuration file.

To re-configure Oracle Forms settings in NeoLoad, follow these steps:

1. Close NeoLoad.

2. Open the <neoload>/conf/Controller.properties file.

3. If the [OracleForms] settings category does not exist, create it.

4. Underneath the category, create the oracle.forms.session.migration.max.retry key. For example:

   Copy

   oracle.forms.session.migration.max.retry=5

   This key sets the maximum number of attempts before returning an error at 5. By default, NeoLoad makes a maximum of 5 attempts. The key value must be an integer more than or equal to 1.

5. Create the oracle.forms.session.migration.retry.delay key. For example:

   Copy

   oracle.forms.session.migration.retry.delay=1000

   This key sets the interval between attempts, in milliseconds. By default, NeoLoad applies an interval of 1000 milliseconds. The value must be an integer more than or equal to 1000.

6. Save the configuration file.

7. Re-start NeoLoad.

Problem

After an Oracle Forms load test, several frmweb.exe processes remain on the server.

Solution

Check the following:

1. Make sure each Virtual User quits the Oracle Forms application correctly. If this is the case, the last Oracle Forms request will be named something like session_close and its HTTP header should contain ifSession: close.

2. Make sure the stop policy for each Population is set to Indeterminate: allow all Virtual Users to end their actions.