Troubleshooting stubs
You can troubleshoot common problems that you might encounter while you use stubs.
Problem | Resolution |
---|---|
The stub produces the following error message in its console
output:
|
This error appears when a Send Reply action is unable to communicate with the client system
that issued the request message. The most likely cause is that the client already received a reply
from another Send Reply action within the stub and its connection is closed. This situation can occur when you have multiple events in the same HTTP stub that processes the same messages. If the filtering configuration enables multiple events to reply to the same message, only one of them succeeds. The second Send Reply action fails with this error as the client is disconnected. Check your filtering configuration to prevent multiple matches in different events. Consider redesigning the stub to have a single event for these messages. Duplicate the event for each message type and configure filtering. |
The stub does not log events. | In the Environments dashboard for HCL Quality Server (or
in HCL OneTest™ API), verify that the stub was configured to
log events. Alternatively, if |
HCL OneTest™ API cannot configure routing to the stub. | When starting a stub in HCL OneTest™ API, you might
see the following error on the
console:
This error might also appear in the HCL OneTest™ API Agent log file. The problem occurs when you create two stubs with the same transport and operation and try to run both stubs simultaneously. The solution is to only run one stub at a time. You can delete one of the stubs. |
The stub runs very slowly. | If logging is enabled, check that the connection to the results database can be established and is of sufficient performance given the volume of messages being written by the stub. |
The stub running on the agent cannot connect to the results database. | Ensure that the computer running the stub and the computer running HCL Quality Server have the required network connection to access the project results database. |
The required database driver is missing. | If you are using a MySQL driver, ensure that it was installed
correctly. If you are using a non-standard JDBC
driver, ensure that it is included in the |
The traffic does not route to the stub. | When there is a problem, verify the following items:
If the problem persists, contact the system or network administrator to investigate the DNS resolution problems. |
The proxy or intercept for the transport does not route the traffic to the stub. | When you start stubs, they wait for the external proxies to retrieve the
routing configuration rules from the server before they can complete the initialization process and
start the main steps. Therefore, when you run test suites that use stubs, the tests do not start
until the proxies receive their configuration rules. When there is a problem, verify the
following items:
A sample for the stub console output that indicates that the configuration rule did not
reach the external proxy in the allotted time is as
follows:
In this example, only a single proxy is registered with HCL Quality Server. Either the proxy process stopped and its registration did not time out or the proxy could not connect to HCL Quality Server, and therefore the proxy rules could not be applied in the allotted time. If no proxies are
registered with HCL Quality Server, the
following messages are displayed in the stub console output:
For
more troubleshooting tips, see the related links at the end of the page. |
Publishing stubs from HCL OneTest™ API to
HCL Quality Server
fails with the following error:
|
Free up some space in the disk used by HCL Quality Server.
To know which disk location is used, look in the container.server.properties file
for the workingDirectory property. The default
location of the container.server.properties file
is:
|
The TCP port number configured in the stub is already in use. | Use the netstat command to see which port numbers are in
use by which processes. If the client programs are accessing the stub by using the TCP/HTTP proxy,
you can ignore this warning message. The proxy correctly routes messages to the stub even if it uses
a temporary port number. However, if you must run the stub on a fixed port, use the diagnosis
results to take any of the following actions:
|
The stub does not open in the Stub Editor. | You have created a stub from an operation that is a Subscribe action. The stub
has the opposite messaging action, which is a Publish action. This type of stub cannot be edited in
the Stub Editor. You must edit it by using the Test Editor, which is normally used for editing test
sequences. When you create a stub, its messaging actions are the reverse of the operation in order to simulate the server end of the communication. For example, a Send Request/Receive Reply operation gives a stub of the form Receive Request/Send Reply. This type of stub has a Message Switch action and by default is edited in the Stub Editor. You can edit it in the Test Editor by right-clicking the object in the Test Factory tree and selecting . This option is not recommended for more complex stubs.For a subscribe operation, the stub action is Publish. You cannot edit this action in the Stub Editor because it expects an input message. Editing this type of stub opens the Test Editor and you can see the Publish action for a test. |
The stub routing rule uses a wrong network address. | When you run a stub on a system that has multiple network addresses, the
routing rule sent to HCL Quality Server might use
the wrong network address. If the network address used is not accessible from the proxy, messages cannot be routed to the stub. Add the following system environment variable on the system that
is running the stub to force the required rule address:
Restart the system to use the setting. |