This topic provides details specific to working with the local Virtualize Server. For an overview of local vs. remote Virtualize servers, see Local and Remote Deployment Options.

In this section:

Starting and Stopping the Server

The local Virtualize server can be started and stopped from the Virtualize Server view or from the command line.

Starting and stopping the server is essentially starting and stopping:

• The Web server, which includes the Virtualize Server API (Web service interface) and virtual assets that are configured with HTTP.
• JMS and MQ connections, queue session connections, and topic subscription listeners.
• Any configured custom listeners associated with custom extensions.

From the GUI

Starting the Server

To start the local Virtualize server:

1. Open the Virtualize Server view (if it is not available, choose Window> Show View> Virtualize Server).
2. If the Server node does not have a green ball icon to the left of it, start the local Virtualize server in one of the following ways:
   • Right-click the Server node and choose Start Server.
     
     
     
     
   • Select the Server node, then click Start Server in the Virtualize Server view’s toolbar.
     
     

Stopping the Server

You can stop the local Virtualize server (making any virtual assets on the local Virtualize server inaccessible) in any of the following ways:

• Right-click the Server node and select Stop Server.
• Select the Server node, then click Stop Server in the Virtualize Server view’s toolbar.
  
  

From the Command Line

The virtualizecli command line interface is located in the <INSTALL_HOME> directory. Run the application with the available command line options to start the local Virtualize server, e.g.:

virtualizecli -startServer -data <workspace_dir> -localsettings <localsettings_file> file .

When starting Virtualize in this way, the Start deactivated, release automatically when idle option (in Parasoft> Preferences> Parasoft> License) needs to be disabled. Otherwise, you won’t be able to add this server from another Virtualize installation’s UI.

Available Command Line Options

You can use the following command line options with virtualizecli:

• -StartServer: Starts the local Virtualize server from the command line.
• -data: Specifies the Eclipse workspace location. If the -data option is not used, then the default workspace found under [Virtualize_workspace]\parasoft\workspace (where "Virtualize_workspace" could be C:\Users\yourname) will be used.
• -localsettings: Controls various settings for CTP, licensing, and more. You can use the same options available across Parasoft Test products (e.g., Parasoft SOAtest). You can also use options that are specific to Virtualize and CTP. See Localsettings for details.
• -prefs: Reads the %PREFS_URL% preference URL to import Eclipse workspace preferences.%PREFS_URL% is interpreted as a URL or the path to a local Eclipse workspace preferences file. For example:
  -prefs "http://intranet.acme.com/Virtualize/workspace.properties"
-prefs "workspace.properties"\
• -disableEventMonitoring: Disables all event monitoring for this server.
• -machineid: Prints the machine ID, which is used for licensing purposes. 
• -Dparasoft.async.support.mode=<mode>: This property sets the asynchronous processing mode. Asynchronous processing enables better concurrency when responders are configured with delays (e.g., in performance profiles). JMS, MQ and Http Listeners support asynchronous processing. You can specify the following modes:
  • ON - all requests are processed asynchronously
  • DELAY - only response that have a delay are processed asynchronously, default
  • OFF - no asynchronous processing
• -Dparasoft.async.support.workers: The number of worker threads for performing asynchronous processing. Default is 200. 

Deploying Virtual Assets

For instructions on how to deploy virtual assets to the local Virtualize server, see Deploying Virtual Assets - Overview. 

Saving Deployment Changes

If you want to save local virtual asset settings before exiting Virtualize, right-click the Local machine node in the Virtualize Server view and choose Save Deployment Changes.

Collecting Server Statistics

If your organization wants to monitor asset usage statistics for this server, you can configure the server to collect statistics, then view the collected statistics from either Virtualize or the CTP interface.

Server statistics collection can help you:

• Track PVA/responder usage levels and patterns from different groups/divisions over time.
• Assess how close you are to reaching the licensed number of hits.
• Determine how Virtualize response times influence your performance testing results.

Enabling Statistics Collection

To view and modify server statistics collection:

1. Start Virtualize Server in GUI mode.
2. In that GUI, open the configuration panel for the server you want visibility into (double-click its Virtualize Server view node).
3. In the Server Configuration tab, review and modify the available options:
   • Enable the statistics collection service: Enables/disables statistics collection for this server. Collection is enabled by default.
   • Statistics provider: Specifies the provider that the statistics service uses. By default, a built-in provider based on ActiveMQ is used. To use another provider, select it from the list of available options, then complete the applicable fields.
   • Port: The default service port number 9618, but a different port number will automatically be assigned based on availability if that port is in use. You can also configure the port by setting the following property in your JVM arguments on startup:

     parasoft.server.statistics.broker.port=<port>

      
   • Collection period: Determines the frequency (in seconds) at which statistical usage messages are aggregated and reported.

Reviewing Server Statistics

To see a summary of server statistics in Virtualize, open the Virtualize server’s configuration panel, then review the statistics in the Monitoring tab.



"Unrecognized" refers to messages that were received by the Virtualize server, but did not match the listening paths on any virtual asset or HTTP proxy.

"Unmatched" refers to request messages that matched a virtual asset, but failed to match any responder correlations. The unmatched hits are grouped according to the request’s source IP/host and the first virtual asset that attempts to serve this request.

Additional details are available for viewing and export in CTP: