Troubleshooting stubs

You can troubleshoot common problems that you might encounter while you use stubs.

Table 1. Resolutions for problems with stubs
Problem	Resolution
The stub produces the following error message in its console output: `[CRRIT1717E] The socket associated with the request message is no longer available.`	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 DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) (or in HCL DevOps Test Integrations and APIs (Test Integrations and APIs)), verify that the stub was configured to log events. Alternatively, if `localhost` was configured as the logging URL, logging cannot work if the stub is run on a different agent.
Test Integrations and APIs cannot configure routing to the stub.	When starting a stub in Test Integrations and APIs, you might see the following error on the console: `[CRRIT8674E] Unable to configure routing to the stub: 409 Conflict.` This error might also appear in the HCL DevOps Test Integrations and APIs Agent (Test Integrations and APIs 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 Test Virtualization Control Panel 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 `CLASSPATH` of the computer where Test Virtualization Control Panel is installed.
The traffic does not route to the stub.	When there is a problem, verify the following items: Check the routing rule in the Test Virtualization Control Panel, Infrastructure Dashboard. If the rule is missing or has an incorrect hostname or IP address, fix it and then restart the stub. Check the stub console output that is available in the location that contains the agent logs. While starting the stub, a warning message, `"Failed to resolve hostname"` might be displayed. This issue occurs if the DNS lookup fails and the routing rules are not created correctly. To resolve this issue, check whether you have connected to the correct network, specifically check whether the stub or environment is using host names from a private network. 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: The proxy is registered for the domain that is selected in the Test Integrations and APIs project settings and the project's current environment or the proxy is registered for all the domains and environments. The proxy is running and there are no networking problems. Check the status of the proxy on the Infrastructure Dashboard in Test Virtualization Control Panel or in the HTTP/TCP proxy logs. 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: [03/02/2015 11:41:21.382 AM] - - - - Starting initialization - - - - [03/02/2015 11:41:21.382 AM] [Infrastructure] Sending routing configuration to Test Virtualization Control Panel... [03/02/2015 11:41:28.394 AM] [Infrastructure] [CRRIT8674E] Unable to configure routing to the stub: None of the available connected agents have been successfully configured. There are currently 1 connected agent(s) registered with Test Virtualization Control Panel. [03/02/2015 11:41:28.394 AM] [Infrastructure] Application traffic in the environment will not be automatically routed to the stub. In this example, only a single proxy is registered with Test Virtualization Control Panel. Either the proxy process stopped and its registration did not time out or the proxy could not connect to Test Virtualization Control Panel, and therefore the proxy rules could not be applied in the allotted time. If no proxies are registered with Test Virtualization Control Panel, the following messages are displayed in the stub console output: [03/02/2015 11:45:01.861 AM] - - - - Starting initialization - - - - [03/02/2015 11:45:01.861 AM] [Infrastructure] Sending routing configuration to Test Virtualization Control Panel... [03/02/2015 11:45:01.873 AM] [Infrastructure] [CRRIT8674E] Unable to configure routing to the stub: There are no connected HTTP(S) agents registered with Test Virtualization Control Panel in domain "default" and environment "example.com with proxy". Please check the configuration of the agents and control panel. [03/02/2015 11:45:01.873 AM] [Infrastructure] Application traffic in the environment will not be automatically routed to the stub. For more troubleshooting tips, see the related links at the end of the page.
Publishing stubs from Test Integrations and APIs to Test Virtualization Control Panel fails with the following error: `Error: 507 (Insufficient Storage).`	Free up some space in the disk used by Test Virtualization Control Panel. 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: Windows systems: `C:\Program Files\HCL\DevOpsTestControlPanel\usr\servers\defaultServer\apps\RTCP.war\WEB-INF\classes` Systems other than Windows: `/opt/HCL/DevOpsTestControlPanel/usr/servers/defaultServer/apps/RTCP.war/WEB-INF/classes`
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: Configure a different port number for the stub. Either select a different transport for the operation in Architecture School > Logical View or modify the existing transport to use a different port number. End the program that is using the port number and restart the stub.
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 Open With > Test Editor. 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 Test Virtualization Control Panel 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: `RULE_HOST=192.168.1.1` Restart the system to use the setting.
The stubs are not starting on the engines configured on Test Virtualization Control Panel.	When you have configured more than 10 engines to start concurrently on Test Virtualization Control Panel on which the stubs are to be run, you encounter this problem. To resolve this problem, you must edit the Agent.config file that is located in the <Agent_installation_folder>/config directory and change the following values: Change the value of maxConcurrentStarts to the number of engines that you want to start concurrently. Change the value of concurrencyPeriodSecs to the time within which all the engines must start after the first engine is started. You must save the changed configuration and restart the agent before you start the stubs.