The handlers set for the coordinated futures are overridden by the handler of the composite future.

When Vert.x provides an event to a handler or calls the start or stop methods of a \io\vertx\jphp\core\io.vertx.core.Verticle, the execution is associated with a Context.

Usually a context is an *event-loop context* and is tied to a specific event loop thread. So executions for that context always occur on that exact same event loop thread.

In the case of worker verticles and running inline blocking code a worker context will be associated with the execution which will use a thread from the worker thread pool.

When a handler is set by a thread associated with a specific context, the Vert.x will guarantee that when that handler is executed, that execution will be associated with the same context.

If a handler is set by a thread not associated with a context (i.e. a non Vert.x thread). Then a new context will be created for that handler.

In other words, a context is propagated.

This means that when a verticle is deployed, any handlers it sets will be associated with the same context - the context of the verticle.

This means (in the case of a standard verticle) that the verticle code will always be executed with the exact same thread, so you don't have to worry about multi-threaded acccess to the verticle state and you can code your application as single threaded.

This class also allows arbitrary data to be @see \io\vertx\jphp\core\Context::put and @see \io\vertx\jphp\core\Context::get on the context so it can be shared easily amongst different handlers of, for example, a verticle instance.

This class also provides @see \io\vertx\jphp\core\Context::runOnContext which allows an action to be executed asynchronously using the same context.

It's useful in Vert.x to represent things in Vert.x like HTTP headers and HTTP parameters which allow multiple values for keys.

Pausing the timer inhibits the timer shots until the stream is resumed. Setting a null handler callback cancels the timer.

You use an instance of this class for functionality including:

• Creating TCP clients and servers
• Creating HTTP clients and servers
• Creating DNS clients
• Creating Datagram sockets
• Setting and cancelling periodic and one-shot timers
• Getting a reference to the event bus API
• Getting a reference to the file system API
• Getting a reference to the shared data API
• Deploying and undeploying verticles

Most functionality in Vert.x core is fairly low level.

To create an instance of this class you can use the static factory methods: @see \io\vertx\jphp\core\Vertx::vertx,

It provides the same executeBlocking operation than @see \io\vertx\jphp\core\Context and

A buffer is a sequence of zero or more bytes that can read from or written to and which expands automatically as necessary to accommodate any bytes written to it. You can perhaps think of a buffer as smart byte array.

Please consult the documentation for more information on buffers.

..). This interface is polyglot to ease reuse such as in Vert.x Shell.

A command line interface has a name, and defines a set of options and arguments. Options are key-value pair such as -foo=bar or -flag. The supported formats depend on the used parser. Arguments are unlike options raw values. Options are defined using

Short name is generally used with a single dash, while long name requires a double-dash.

Usually you use a datagram socket 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.

Please consult the documentation for more information on datagram sockets.

Please consult the documentation for more information on DNS clients.

Used with event bus interceptors.

Delivery options allow to configure delivery timeout and message codec name, and to provide any headers that you wish to send with the message.

An event-bus supports publish-subscribe messaging, point-to-point messaging and request-response messaging.

Message delivery is best-effort and messages can be lost if failure of all or part of the event bus occurs.

Please refer to the documentation for more information on the event bus.

Messages have a @see \io\vertx\jphp\core\eventbus\Message::body, which can be null, and also @see \io\vertx\jphp\core\eventbus\Message::headers, which can be empty.

If the message was sent specifying a reply handler, it can be replied to using @see \io\vertx\jphp\core\eventbus\Message::reply.

If you want to notify the sender that processing failed, then @see \io\vertx\jphp\core\eventbus\Message::fail can be called.

The @see \io\vertx\jphp\core\eventbus\EventBus::consumer or @see \io\vertx\jphp\core\eventbus\EventBus::localConsumer creates a new consumer, the returned consumer is not yet registered against the event bus. Registration is effective after the @see \io\vertx\jphp\core\eventbus\MessageConsumer::handler method is invoked.

The consumer is unregistered from the event bus using the @see \io\vertx\jphp\core\eventbus\MessageConsumer::unregister method or by calling the

This class also implements @see \io\vertx\jphp\core\streams\ReadStream and

A (potential) blocking and non blocking version of each operation is provided.

The non blocking versions take a handler which is called when the operation completes or an error occurs.

The blocking versions are named xxxBlocking and return the results, or throw exceptions directly. In many cases, depending on the operating system and file system some of the potentially blocking operations can return quickly, which is why we provide them, but it's highly recommended that you test how long they take to return in your particular application before using them on an event loop.

Please consult the documentation for more information on file system support.

The settings expose the parameters defined by the HTTP/2 specification, as well as extra settings for protocol extensions.

It allows you to make requests to HTTP servers, and a single client can make requests to any server.

It also allows you to open WebSockets to servers.

The client can also pool HTTP connections.

For pooling to occur, keep-alive must be true on the @see \io\vertx\jphp\core\http\HttpClientOptions (default is true). In this case connections will be pooled and re-used if there are pending HTTP requests waiting to get a connection, otherwise they will be closed.

This gives the benefits of keep alive when the client is loaded but means we don't keep connections hanging around unnecessarily when there would be no benefits anyway.

The client also supports pipe-lining of requests. Pipe-lining means another request is sent on the same connection before the response from the preceding one has returned. Pipe-lining is not appropriate for all requests.

To enable pipe-lining, it must be enabled on the @see \io\vertx\jphp\core\http\HttpClientOptions (default is false).

When pipe-lining is enabled the connection will be automatically closed when all in-flight responses have returned and there are no outstanding pending requests to write.

The client is designed to be reused between requests.

Instances are created by an @see \io\vertx\jphp\core\http\HttpClient instance, via one of the methods corresponding to the specific HTTP methods, or the generic request methods. On creation the request will not have been written to the wire.

Once a request has been obtained, headers can be set on it, and data can be written to its body if required. Once you are ready to send the request, one of the @see \io\vertx\jphp\core\http\HttpClientRequest::end methods should be called.

Nothing is actually sent until the request has been internally assigned an HTTP connection.

The @see \io\vertx\jphp\core\http\HttpClient instance will return an instance of this class immediately, even if there are no HTTP connections available in the pool. Any requests sent before a connection is assigned will be queued internally and actually sent when an HTTP connection becomes available from the pool.

The headers of the request are queued for writing either when the @see \io\vertx\jphp\core\http\HttpClientRequest::end method is called, or, when the first part of the body is written, whichever occurs first.

This class supports both chunked and non-chunked HTTP.

It implements @see \io\vertx\jphp\core\streams\WriteStream so it can be used with

Vert.x provides you with one of these via the handler that was provided when creating the @see \io\vertx\jphp\core\http\HttpClientRequest or that was set on the @see \io\vertx\jphp\core\http\HttpClientRequest instance.

It implements @see \io\vertx\jphp\core\streams\ReadStream so it can be used with

HTTP/1.x connection provides an limited implementation, the following methods are implemented:

• @see \io\vertx\jphp\core\http\HttpConnection::close
• @see \io\vertx\jphp\core\http\HttpConnection::closeHandler
• @see \io\vertx\jphp\core\http\HttpConnection::exceptionHandler

You receive HTTP requests by providing a @see \io\vertx\jphp\core\http\HttpServer::requestHandler. As requests arrive on the server the handler will be called with the requests.

You receive WebSockets by providing a @see \io\vertx\jphp\core\http\HttpServer::websocketHandler. As WebSocket connections arrive on the server, the WebSocket is passed to the handler.

Instances are created for each request and passed to the user via a handler.

Each instance of this class is associated with a corresponding @see \io\vertx\jphp\core\http\HttpServerResponse instance via

An instance of this is created and associated to every instance of

Instances of this class are passed into a @see \io\vertx\jphp\core\http\HttpServer::websocketHandler or provided when a WebSocket handshake is manually @see \io\vertx\jphp\core\http\HttpServerRequest::upgradeed.

It implements both and so it can be used with

A WebSocket message is composed of one or more WebSocket frames.

If there is a just a single frame in the message then a single text or binary frame should be created with final = true.

If there are more than one frames in the message, then the first frame should be a text or binary frame with final = false, followed by one or more continuation frames. The last continuation frame should have final = true.

When used as a key store, it should point to a store containing a private key and its certificate. When used as a trust store, it should point to a store containing a list of trusted certificates.

The store can either be loaded by Vert.x from the filesystem:

HttpServerOptions options = HttpServerOptions.httpServerOptions();
options.setKeyStore(new JKSOptions().setPath("/mykeystore.jks").setPassword("foo"));

Buffer store = vertx.fileSystem().readFileSync("/mykeystore.jks");
options.setKeyStore(new JKSOptions().setValue(store).setPassword("foo"));

Multiple connections to different servers can be made using the same instance.

This client supports a configurable number of connection attempts and a configurable delay between attempts.

Instances of this class are created on the client side by an @see \io\vertx\jphp\core\net\NetClient when a connection to a server is made, or on the server side by a @see \io\vertx\jphp\core\net\NetServer when a server accepts a connection.

It implements both and so it can be used with

A key file must contain a non encrypted private key in PKCS8 format wrapped in a PEM block, for example:

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDV6zPk5WqLwS0a
...
K5xBhtm1AhdnZjx5KfW3BecE
-----END PRIVATE KEY-----

Or contain a non encrypted private key in PKCS1 format wrapped in a PEM block, for example:

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAlO4gbHeFb/fmbUF/tOJfNPJumJUEqgzAzx8MBXv9Acyw9IRa
...
zJ14Yd+t2fsLYVs2H0gxaA4DW6neCzgY3eKpSU0EBHUCFSXp/1+/
-----END RSA PRIVATE KEY-----

A certificate file must contain an X.509 certificate wrapped in a PEM block, for example:

-----BEGIN CERTIFICATE-----
MIIDezCCAmOgAwIBAgIEZOI/3TANBgkqhkiG9w0BAQsFADBuMRAwDgYDVQQGEwdV
...
+tmLSvYS39O2nqIzzAUfztkYnUlZmB0l/mKkVqbGJA==
-----END CERTIFICATE-----

HttpServerOptions options = new HttpServerOptions();
options.setPemKeyCertOptions(new PemKeyCertOptions().setKeyPath("/mykey.pem").setCertPath("/mycert.pem"));

Buffer key = vertx.fileSystem().readFileSync("/mykey.pem");
Buffer cert = vertx.fileSystem().readFileSync("/mycert.pem");
options.setPemKeyCertOptions(new PemKeyCertOptions().setKeyValue(key).setCertValue(cert));

HttpServerOptions options = new HttpServerOptions();
options.setPemKeyCertOptions(new PemKeyCertOptions()
   .addKeyPath("/mykey1.pem").addCertPath("/mycert1.pem")
   .addKeyPath("/mykey2.pem").addCertPath("/mycert2.pem"));

Validating certificates must contain X.509 certificates wrapped in a PEM block:

-----BEGIN CERTIFICATE-----
MIIDezCCAmOgAwIBAgIEVmLkwTANBgkqhkiG9w0BAQsFADBuMRAwDgYDVQQGEwdV
...
z5+DuODBJUQst141Jmgq8bS543IU/5apcKQeGNxEyQ==
-----END CERTIFICATE-----

HttpServerOptions options = new HttpServerOptions();
options.setPemTrustOptions(new PemTrustOptions().addCertPath("/cert.pem"));

Buffer cert = vertx.fileSystem().readFileSync("/cert.pem");
HttpServerOptions options = new HttpServerOptions();
options.setPemTrustOptions(new PemTrustOptions().addCertValue(cert));

When used as a key store, it should point to a store containing a private key and its certificate. When used as a trust store, it should point to a store containing a list of accepted certificates.

The store can either be loaded by Vert.x from the filesystem:

HttpServerOptions options = new HttpServerOptions();
options.setPfxKeyCertOptions(new PfxOptions().setPath("/mykeystore.p12").setPassword("foo"));

Buffer store = vertx.fileSystem().readFileSync("/mykeystore.p12");
options.setPfxKeyCertOptions(new PfxOptions().setValue(store).setPassword("foo"));

While it helps for testing and development, it should never ever be used in production settings.

Use @see \io\vertx\jphp\core\net\SocketAddress::inetSocketAddress to create an inet socket address and @see \io\vertx\jphp\core\net\SocketAddress::domainSocketAddress to create a domain socket address

The parser also parses concatenated json streams or line delimited json streams.

The parser can also parse entire object or array when it is convenient, for instance a very large array of small objects can be parsed efficiently by handling array start/end and object events.

Whenever the parser fails to parse or process the stream, the @see \io\vertx\jphp\core\parsetools\JsonParser::exceptionHandler is called with the cause of the failure and the current handling stops. After such event, the parser should not handle data anymore.

Instances of this class take as input @see \io\vertx\jphp\core\buffer\Buffer instances containing raw bytes, and output records.

For example, if I had a simple ASCII text protocol delimited by '\n' and the input was the following:

buffer1:HELLO\nHOW ARE Y
buffer2:OU?\nI AM
buffer3: DOING OK
buffer4:\n

buffer1:HELLO
buffer2:HOW ARE YOU?
buffer3:I AM DOING OK

Instances of this class can't currently be used for protocols where the text is encoded with something other than a 1-1 byte-char mapping.

Please see the documentation for more information.

By default the map allows immutable keys and values. Custom keys and values should implement \io\vertx\jphp\core\shareddata\io.vertx.core.shareddata.Shareable interface. The map returns their copies.

This ensures there is no shared access to mutable state from different threads (e.g. different event loops) in the Vert.x instance, and means you don't have to protect access to that state using synchronization or locks.

Since the version 3.4, this class extends the interface. However some methods are only accessible in Java.

When the lock is obtained, no-one else in the cluster can obtain the lock with the same name until the lock is released.

Shared data provides:

• synchronous shared maps (local)
• asynchronous maps (local or cluster-wide)
• asynchronous locks (local or cluster-wide)
• asynchronous counters (local or cluster-wide)

WARNING: In clustered mode, asynchronous maps/locks/counters rely on distributed data structures provided by the cluster manager. Beware that the latency relative to asynchronous maps/locks/counters operations can be much higher in clustered than in local mode.

Instances of this class read items from a @see \io\vertx\jphp\core\streams\ReadStream and write them to a @see \io\vertx\jphp\core\streams\WriteStream. If data can be read faster than it can be written this could result in the write queue of the @see \io\vertx\jphp\core\streams\WriteStream growing without bound, eventually causing it to exhaust all available RAM.

To prevent this, after each write, instances of this class check whether the write queue of the @see \io\vertx\jphp\core\streams\WriteStream is full, and if so, the @see \io\vertx\jphp\core\streams\ReadStream is paused, and a drainHandler is set on the

Any class that implements this interface can be used by a @see \io\vertx\jphp\core\streams\Pump to pump data from it to a @see \io\vertx\jphp\core\streams\WriteStream.

Streaming mode

Initially the stream is in flowing mode.
• When the stream is in flowing mode, elements are delivered to the handler.
• When the stream is in fetch mode, only the number of requested elements will be delivered to the handler.

• Calling @see \io\vertx\jphp\core\streams\ReadStream::resume sets the flowing mode
• Calling @see \io\vertx\jphp\core\streams\ReadStream::pause sets the fetch mode and resets the demand to 0
• Calling @see \io\vertx\jphp\core\streams\ReadStream::fetch requests a specific amount of elements and adds it to the actual demand

Any class that implements this interface can be used by a @see \io\vertx\jphp\core\streams\Pump to pump data from a ReadStream to it.