Skip to content

Instantly share code, notes, and snippets.

@echarles

echarles/gist:6079534

Created July 25, 2013 13:19
Show Gist options
  • Save echarles/6079534 to your computer and use it in GitHub Desktop.
Save echarles/6079534 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
eric:java eric$ vertx version
2.0.0-final (built 2013-07-17 22:04:19)
eric:java eric$ vertx httpperf/PerfClient.java -instances 6 -cluster
vertx run <main> [-options]
runs a verticle called <main> in its own instance of vert.x.
<main> can be a JavaScript script, a Ruby script, A Groovy script,
a Java class, a Java source file, or a Python Script.
valid options are:
-conf <config_file> Specifies configuration that should be provided
to the verticle. <config_file> should reference
a text file containing a valid JSON object
which represents the configuration.
-cp <path> specifies the path on which to search for
<main> and any referenced resources.
Defaults to '.' (current directory).
-instances <instances> specifies how many instances of the verticle
will be deployed. Defaults to 1
-worker if specified then the verticle is a worker
verticle.
-includes <mod_list> optional comma separated list of modules
which will be added to the classpath of
the verticle.
-cluster if specified then the vert.x instance will form
a cluster with any other vert.x instances on
the network.
-cluster-port port to use for cluster communication.
Default is 0 which means chose a spare
random port.
-cluster-host host to bind to for cluster communication.
If this is not specified vert.x will attempt
to choose one from the available interfaces.
vertx runmod <modname> [-options]
runs a module called <modname> in its own instance of vert.x.
If the module is not already installed, Vert.x will attempt to install
it from a repository before running it.
valid options are:
-conf <config_file> Specifies configuration that should be provided
to the module. <config_file> should reference
a text file containing a valid JSON object
which represents the configuration.
-instances <instances> specifies how many instances of the verticle
will be deployed. Defaults to 1
-cluster if specified then the vert.x instance will form
a cluster with any other vert.x instances on
the network.
-cluster-port port to use for cluster communication.
Default is 0 which means chose a spare
random port.
-cluster-host host to bind to for cluster communication.
If this is not specified vert.x will attempt
to choose one from the available interfaces.
-cp <path> if specified Vert.x will attempt to find the
module on the classpath represented by this
path and not in the modules directory
vertx runzip <zipfilename> [-options]
installs then deploys a module which is contained in the zip specified
by <zipfilename>. The module will be installed with a name given by
<zipfilename> without the .zip extension. If a module with that name
is already installed this will do nothing.
The options accepted by this command are exactly the same as those
accepted by vertx runmod
vertx install <modname> [-options]
attempts to install a module from a remote repository.
Module will be installed into a local 'mods' directory or, if the
module is marked as a system module, the sys-mods directory in the
Vert.x installation unless the
environment variable VERTX_MODS specifies a different location.
vertx uninstall <modname>
attempts to uninstall a module from a remote repository.
Module will be uninstalled from the local 'mods' directory unless the
environment variable VERTX_MODS specifies a different location.
vertx pulldeps <modname>
Pulls in the tree of dependencies of the module and puts them in the
nested module directory (mods) of the module. This allows the module
to be a completely self contained unit containing all the modules it
needs to run.
Vert.x will consult the 'includes' and 'deploys' fields to determine
which modules to pull in.
vertx version
displays the version
eric:java eric$ vertx httpperf/PerfClient.java -cluster -instances 6
vertx run <main> [-options]
runs a verticle called <main> in its own instance of vert.x.
<main> can be a JavaScript script, a Ruby script, A Groovy script,
a Java class, a Java source file, or a Python Script.
valid options are:
-conf <config_file> Specifies configuration that should be provided
to the verticle. <config_file> should reference
a text file containing a valid JSON object
which represents the configuration.
-cp <path> specifies the path on which to search for
<main> and any referenced resources.
Defaults to '.' (current directory).
-instances <instances> specifies how many instances of the verticle
will be deployed. Defaults to 1
-worker if specified then the verticle is a worker
verticle.
-includes <mod_list> optional comma separated list of modules
which will be added to the classpath of
the verticle.
-cluster if specified then the vert.x instance will form
a cluster with any other vert.x instances on
the network.
-cluster-port port to use for cluster communication.
Default is 0 which means chose a spare
random port.
-cluster-host host to bind to for cluster communication.
If this is not specified vert.x will attempt
to choose one from the available interfaces.
vertx runmod <modname> [-options]
runs a module called <modname> in its own instance of vert.x.
If the module is not already installed, Vert.x will attempt to install
it from a repository before running it.
valid options are:
-conf <config_file> Specifies configuration that should be provided
to the module. <config_file> should reference
a text file containing a valid JSON object
which represents the configuration.
-instances <instances> specifies how many instances of the verticle
will be deployed. Defaults to 1
-cluster if specified then the vert.x instance will form
a cluster with any other vert.x instances on
the network.
-cluster-port port to use for cluster communication.
Default is 0 which means chose a spare
random port.
-cluster-host host to bind to for cluster communication.
If this is not specified vert.x will attempt
to choose one from the available interfaces.
-cp <path> if specified Vert.x will attempt to find the
module on the classpath represented by this
path and not in the modules directory
vertx runzip <zipfilename> [-options]
installs then deploys a module which is contained in the zip specified
by <zipfilename>. The module will be installed with a name given by
<zipfilename> without the .zip extension. If a module with that name
is already installed this will do nothing.
The options accepted by this command are exactly the same as those
accepted by vertx runmod
vertx install <modname> [-options]
attempts to install a module from a remote repository.
Module will be installed into a local 'mods' directory or, if the
module is marked as a system module, the sys-mods directory in the
Vert.x installation unless the
environment variable VERTX_MODS specifies a different location.
vertx uninstall <modname>
attempts to uninstall a module from a remote repository.
Module will be uninstalled from the local 'mods' directory unless the
environment variable VERTX_MODS specifies a different location.
vertx pulldeps <modname>
Pulls in the tree of dependencies of the module and puts them in the
nested module directory (mods) of the module. This allows the module
to be a completely self contained unit containing all the modules it
needs to run.
Vert.x will consult the 'includes' and 'deploys' fields to determine
which modules to pull in.
vertx version
displays the version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment