Vert.x clojure language module API documentation


Functions for operating on Vert.x Buffers.
A Buffer represents a sequence of zero or more bytes that can be
written to or read from, and which expands as necessary to
accommodate any bytes written to it.

append!, set! and as-buffer take several different types of data
that can be written to a buffer these types are referred to
collectively as "bufferable", and are:

* Buffer
* Byte
* byte[]
* Double
* BigDecimal (coerced to a Double)
* Ratio (coerced to a Double)
* Float
* Integer
* Long
* BigInt (coerced to a Long)
* Short
* String


Vert.x core functionality.


Provides a broad set of functions for UDP servers and clients.

Usually you use a Datragram Client to send UDP over the wire. UDP
is connection-less which means you are not connected to the remote
peer in a persistent way. Because of this you have to supply the
address and port of the remote peer when sending data.

You can send data to ipv4 or ipv6 addresses, which also include
multicast addresses.


Provides functions for asynchronous DNS operations.

Public variables and functions:


Functions for running Vert.x embedded.

Public variables and functions:


Functions for running Vert.x embedded with a platform manager.


Functions for operating on the Vert.x EventBus and its Messages.
The event bus implements publish / subscribe, point to point
messaging and request-response messaging.

Messages sent over the event bus are represented by instances of
the class.

For publish / subscribe, messages can be published to an address
using publish function. An address is a simple String instance.

Handlers are registered against an address. There can be multiple
handlers registered against each address, and a particular handler
can be registered against multiple addresses. The event bus will
route a sent message to all handlers which are registered against
that address.

For point to point messaging, messages can be sent to an address
using the send function. The messages will be delivered to a single
handler, if one is registered on that address. If more than one
handler is registered on the same address, Vert.x will choose one
and deliver the message to that. Vert.x will aim to fairly
distribute messages in a round-robin way, but does not guarantee
strict round-robin under all circumstances.

All messages sent over the bus are transient. On event of failure
of all or part of the event bus messages may be lost. Applications
should be coded to cope with lost messages, e.g. by resending them,
and making application services idempotent.

The order of messages received by any specific handler from a
specific sender should match the order of messages sent from that

When sending a message, a reply handler can be provided. If so, it
will be called when the reply from the receiver has been
received. Reply messages can also be replied to, etc, ad infinitum.

Different event bus instances can be clustered together over a
network, to give a single logical event bus.

If handlers are registered from an event loop, they will be
executed using that same event loop. If they are registered from
outside an event loop (i.e. when using Vert.x embedded) then Vert.x
will assign an event loop to the handler and use it to deliver
messages to that handler.


Provides a broad set of functions for manipulating files. Wraps the
asynchronous methods from


Provides a broad set of functions for manipulating files. Wraps the
synchronous methods from


Provides a broad set of functions for creating HTTP servers and
clients, and handling requests.


Functions for operating on Vertx.x RouteMatcher.
RouteMatchers allows you to do route requests based on the HTTP
verb and the request URI, in a manner similar Sinatra or Express.

RouteMatchers also let you extract parameters from the request URI
either a via simple pattern or using regular expressions for more
complex matches. Any parameters extracted will be added to the
requests parameters which will be available to you in your request


This is an implementation of the server side part of

SockJS enables browsers to communicate with the server using a
simple WebSocket-like api for sending and receiving messages. Under
the bonnet SockJS chooses to use one of several protocols depending
on browser capabilities and what appears to be working across the

Available protocols include:

* WebSockets
* xhr-polling
* xhr-streaming
* json-polling
* event-source
* html-file

This means it should just work irrespective of what browser
is being used, and whether there are nasty things like proxies and
load balancers between the client and the server.

For more detailed information on SockJS, see their website.

On the server side, you interact using instances of SockJSSocket -
this allows you to send data to the client or receive data via

You can register multiple applications with the same SockJSServer,
each using different path prefixes, each application will have its
own handler, and configuration.


Provides a set of functions for using http websockets.


Functions for logging to the Vert.x logging subsystem.

Provides a broad set of functions for creating TCP servers and


Functions for managing nREPLs within a Vert.x container.

Public variables and functions:


Functions for sharing data between verticles on the same Vert.x instance.

Functions that operate on Vert.x ReadStreams and WriteStreams.

Public variables and functions: