This topic explains how to configure individual virtual assets deployed to a Virtualize server. Refer to Configuring Server and Deployment Settings for details on configuring Virtualize server settings.
...
Specify a path on the server where the virtual asset will listen for incoming messages over HTTP. If no value is specified, then only JMS, MQ or custom transport listener settings will be applied for receiving messages.
To change the port number, see Using an Alternative Port for the Virtualize HTTP Server. To enable SSL (through HTTPS), see Configuring SSL (HTTPS) for the Virtualize Server.
We recommend giving each virtual asset a unique HTTP path unless you want Virtualize to look into multiple virtual assets when searching for a responder that is configured to respond to the incoming message.
...
Enable this option to indicate a messaging model in which Destination and replyTo queues are specified. After enabling a messaging model, you can either enter the settings for each connection in the Local Settings section or reference a global JMS connection defined at the Virtualize server level (see Connections Tab).
Publish-and-Subscribe
Enable this option to indicate a messaging model in which Publish and Subscribe topics are specified. After enabling a messaging model, you can either enter the settings for each connection in the Local Settings section or reference a global JMS connection defined at the Virtualize server level (see Connections Tab).
Client Publish (Publish-and-Subscribe Mode)
...
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Choose Local Settings to use the provider URL, initial context class, connection factory, and login credentials specified in the Local Settings section, or choose a connection configured on the Virtualize server Connections Tab (see Using Global JMS Connections).
...
Specifies any additional JNDI properties you want applied to this deployment.
Using Global JMS Connections
| Anchor | ||||
|---|---|---|---|---|
|
You can use the connection settings defined in the Virtualize Server configuration. See Connections Tab for details on configuring global JMS connection settings. To use a global JMS connection, choose it from the Settings drop-down menu.
...
Choose Local Settings to use the connection settings configured in the Local Settings section or choose a setting configured in the Connections Tab of the Virtualize server configuration (see Using Global MQ Queues).
...
Choose Local Settings to use the connection settings configured in the Local Settings section or choose a setting configured in the Connections Tab of the Virtualize server configuration (see Using Global MQ Queues).
...
If login credentials are required, specify the password in this field.
Using Global MQ QueuesAnchor Using Global MQ Queues Using Global MQ Queues
| Using Global MQ Queues | |
| Using Global MQ Queues |
If you want to configure queues deployed on different MQ servers within a single virtual asset (e.g., you want a specific virtual asset to use two queues that are deployed on two different MQ servers), you can define them globally at the Virtualize server level, then reference them here. See Connections Tab for details.
...
For details, see Browsing Queues.
Adjusting the Worker Count
| Anchor | ||||
|---|---|---|---|---|
|
Each worker creates its own connection to the MQ/JMS provider. For example, for MQ, if you have 20 workers, your WebSphere MQ Explorer should show the value 20 in the Open input count column for the request (get) queue that the virtual asset is listening on. Whenever an asset is deployed/redeployed with a worker count that is higher than the default value of 1, you should see messages like "Started x listener(s)" in the Console (where x is the number of workers configured).
...
The worker count feature is equivalent to the “maxThreads” attribute in Tomcat server.xml; see Configuring SSL (HTTPS) for the Virtualize Server for details on where to find the server.xml for Virtualize’s Tomcat.
When subjecting Virtualize to a high number of concurrent virtual users (i.e. during a load test), you can usually expect better performance by increasing these values.
...