Core

  • Vertex is an open source project and part of the eclipse foundation.
  • Eclipse vertex is a toolkit for building reactive applications on the JVM.
  • Reactive applications are both scalable as workload goes, and Resilient when failure arise.
  • A reactive application Is responsive as it keeps latency under control by making efficient usage of system resources, and by protecting itself from errors.
  • Vertex is a powerful support for creating built in reactive applications.
  • Vertex core comprises Of following
    • The vertex object
      • The vertex framework is built around the vertex object, which is the Control centre of vertex.
      • We can create servers, clients, interacting with event bus or setting timers.
        • We create these in our Java main class file.
    • Verticals
      • Vertex comes with a scalable actor like deployment and concurrency model out of the box
      • Multiple verticals can be deployed by the vertex instance.
      • Verticals are running on the event loop threads Which are used for non-blocking operations
      • A vertical can be deployed multiple times for scalability.
      • Each child vertical can be deployed multiple times and as each vertical has its own thread, Multiple threads can be used Without Concurrent access issues.
      • Vertical code is executed on the event loop.
        • Vertex uses multiple event loops(Multi-Reactor Pattern)
        • An event loop must not execute blocking code to guarantee A fast processing of events.
        • Vertical code is executed on a non-blocking event loop thread.
        • Inside a vertical thread Safety is guaranteed.
        • Verticals typically communicate over the event bus.
        • Typically, all verticals use the same vertex instance
        • This model is optional
          • But enables concurrency in an easy way.
        • While scaling each vertical gets the same configuration.
    • Event loops
      • Vertical code is executed on a non-blocking event loop thread.
      • When multiple thoughts are processing parallel Lee, some thirds may have to wait for CPU.
      • The solution to avoid waiting time is called as non-blocking I/O.
      • The threads which are executing non-blocking IO are called as event loops
      • All events are added in a queue and event loop thread processes them without any wait time.
      • The event loop thread Should not be blocked, so all events are processed firmly.
      • Each vertex vertical is scheduled an event loop and thus inside a vertical thread safety Is guaranteed and concurrency can happen without concurrent access issues.
      • Sometimes there are operations which are blocking like traditional database, access, thread, sleep, heavy computation, file IO, wait for response from network.
        • These should not be run on an event loop.
      • Run blocking operations on worker threads.
      • Look for warning, like vertex-eventloop-thread-x has been Blocked for Yms
    • Worker Threads
      • Vertex provides worker threads To execute blocking operations, either by calling, vertex, execute, blocking or deploying a worker vertical.
    • The event bus
      • Every vertical works on its own thread, and sometimes they have to communicate with each other.
      • We use Vertex event bus for communication between verticals.
      • The event bus is the nervous system of vertex.
      • It allows event driven communication In a non-blocking thread, Safeway
      • There is only one event, bus per vertex instance Available.
      • It is possible to hook up the event, bus to clients and distribute messages to multiple server nodes.
      • Vertex event bus is used to communicate in a thread safe Way using vertex Jason object.
      • We can send Jason objects over an event bus.
      • The event bus supports three ways of messaging
        • Publish/subscribe messaging
          • One vertical is publishing message that can be consumed by multiple verticals at the same time.
          • It acts as a broadcast message
          • It is possible to distribute messages in a thread safe way to multiple verticals At the same time.
          • You don’t have to worry about concurrency issues as vertex will take care of it.
        • Point to point messaging
          • Communicating over the event, bus is point to point communication.
          • One vertical sends message to another one without any response.
          • We can scale the receiver.
          • With this approach, we can communicate in a thread safe way Between verticals, and we don’t have to worry about concurrency issues.
        • Request response messaging
      • Through the event, bus, the verticals can Communicate with each other, using the above three ways of messaging.
      • Event bus - Custom message, codec
        • We can also send our custom objects over the event bus.
        • They require a bit more configuration and a custom message, codec.
        • By default, vertex does not allow us to send custom Java objects over the event bus. We need a custom message, codec.
        • We have to create a custom message, codec Manually.
        • Custom message, codec Must implement the interface MessageCodec.
        • It should provide the type of message being sent and message being received.
        • The message, codec Provides a way to send one type of message and receive a type of message.
        • We should use immutable objects while using the codec Else, concurrency issues may occur.
        • An immutable object is an object that cannot be changed after it was created.
        • An immutable class only has a constructor to initialise objects and does not have getters and setters. So the properties cannot be changed afterwards.
        • If we want to use mutable objects, we can copy them inside transform method or use the vertex Jason object or vertex Jason array Object.
        • By default, vertex registers, a lot of message codecs already.
        • When we check all the implementation of a message, codec Class, we see there is a Boolean message codec, A buffer message, codec, The real message, codec.
        • We have all the basic types, supported like double, float, integer, and so on.
        • Vertex objects are supported with their codecs Like Jason, message, codec, Jason object message codec.
        • In the codec The function encodeToWire and decodeFromWire Are used for clustered event, bus.
          • encodeToWire Changes the Jason object to a buffer And sends to another event Bus instance.
          • decodeFromWire Uses buffer to convert to JSON object.
          • If we want to have functionality to send objects over a clustered event, bus, we would have to transform them into a buffer and also decode them from a buffer.
        • Transform method is used for local event buses.
          • From the transform function, we return immutable objects.
          • Transform, sends the copy of Jason object Every time it is sent over an event bus.
          • This is a small overhead of the system, but it avoids all kinds of concurrency issues.
          • If we don’t Have immutable objects, we can copy them in the transform function.
        • We have to register a codec Before we use it, we should register only once a codec That is before sending the first message.
        • If we try to register a codec Multiple times, exception will be raised.
      • When we are inside one JVM, we use a local event bus.
    • Vertex future and promises.
  • One thread Does not wait for event to complete the thread processes Events one after the other as fast as possible.
  • Events are aligned in a queue and are processed one after the other.
  • Reactive programming requires the use of callbacks, futures, and messages.
  • Vertex by default supports log4j2 Framework in its internal logging API.
  • Logging API supports other logging back ends as well.
  • Log4j2 Supports Asynchronous logging, which can provide 18 times higher throughput and lower latency.
  • JSON Object
    • Vertex has a built in JSON object and JSON array implementation.
    • Used for working in web application using REST API’s
    • It is possible to convert Java objects to vertex Jason object or send them over the event bus.
  • JSON Array Object
    • A JSON array Is a sequence of values.
    • Values could be of type Number, string, Boolean, or other objects.
    • It is possible to add Jason objects Inside one, Jason array.
  • Mapping Java objects
    • We can convert our objects to Jason object and vice versa since vertex 4.
    • We need to add one dependency to convert objects from and to JSON object.
    • Vertex uses Jackson as Jason processor to do the conversion.
      • Jackson is a high-performance Jason processor that is very common across multiple frameworks.
      • Every object needs to have a proper constructor for getters and setters otherwise, the conversion will fail.
    • Vertex Version four requires at runtime only the Jackson core dependency. Unless Jason or object mapping is needed, then the data binding dependency must also be added.
    • Vertex version three requires Jackson core and Jackson data bind As dependency.
    • So if we are using Version four, converting works out of box as the dependency is always available.
    • Add the dependency in your dependency management tool.
  • Future and promise
    • Vertex uses an asynchronous programming model To achieve scalability and resource efficiency.
    • There are event loops where only asynchronous tasks should be executed in an asynchronous environment.
    • It is possible to Use Call backs to manage tasks and react on different results.
      • Call backs have a disadvantage, Called as Call back hell.
      • Chaining callbacks can get Very messy.
    • In vertex, we have promises and futures.
      • They allow a simple coordination Of asynchronous tasks And are pretty common When using a functional programming approach.
      • Functional programming approach to replace callbacks.
      • Future/promise was there in vertex 3.8 when promise was introduced.
      • Before vertex 3.8 only future was available.
      • Promise is used to write an eventual value and can be completed, or it may be marked as failed.
        • A promise can be created from a promise class.
        • The promise should live in a small context, for example, inside a function.
        • A promise can either be completed or failed.
        • A promise can be completed in multiple ways and may contain different values
          • Promise<Void>
            • Doesn’t contain any value.
          • Promise<String>
            • It completes with a string.
          • Promise<JsonObject>
            • It completes with a new JSON object With key value pairs
            • We can use vertex Jason objects, and Vertex Jason arrays.
      • Future is used to read the value from a promise when it is available.
        • We can think of future as a read and write view on a value.
        • A future can be returned and chained together To act on the result of the promise.
        • Future is the review of a promise and can react on the result.
          • From the promise a future can be created With promise.future()
          • A future has the same return type as the promise. If the promise has type string The content of the future will also be type string.
          • A future can react on the outcome of the promise.
          • A future supports on success and on failure, handlers.
          • We can combine future and coordinate them properly using CompositeFuture.all(Future1,Future2…).
          • It supports the same handlers as the future, and allows to handle multiple futures at once.
        • Futures are used to handle outcomes of a promise.
          • We can also process the result using a future.
          • A map is used to modify a result.
          • We can coordinate multiple futures and chain them together.
          • A composite future can handle multiple futures at once.
        • We can change multiple methods using fluent API with return types as futures.
        • This allows the coordination of asynchronous tasks in a sequential order.
        • We can Chain Multiple tasks using coordinate futures.
        • We can compose to chain multiple methods and return a future from compose.
          • All the compose methods are executed on vertex event loop thread So we should not execute any blocking code here.
        • The composite future provides a way to react on the outcome of multiple futures.
          • Composite future, all expects all futures to be successful, Otherwise, it will fail completely
          • Composite future, any expects any of the future to be successful.
          • Composite future join means before sending the result, all futures Must be returned. Then it has same behaviour as of all.
  • Vertex Launcher
    • When we start a vertex application by using a Java main method in main vertical. And when we exit this application it does not trigger all the stop routines Which is not ideal situation.
    • Vertex uses vertex launcher to achieve this behaviour. It executes a set of commands such as run, bare, start.
    • Vertex launcher can be used in IDE to get clean, start and stop.
    • We can also extend this launcher and write custom logic
    • To use vertex launcher
      • Set the main class of the manifest to io.vertx.core.Launcher
      • In addition, set the main vertical manifest entry to the Name of your main vertical.
    • The launcher has certain exit codes
      • 0 if the process ends Smoothly, or if an uncaught error is shown.
      • 1 for General purpose error.
      • 11 If the vertex cannot be initialised.
      • 12 If a spawn process cannot be started, found or stopped. This error code is used by the start and stop command.
      • 14. If the system configuration is not meeting the system requirement.
      • 15. If the main vertical cannot be deployed.
    • We have shadow/shade Plug-in, which creates a fat jar for our project.
      • Fat jar is a single jar file That contains all the compiled Java classes of a project and also compiled Java classes from all dependencies. No additional Dependences have to be referred.
      • Fat jars are very handy For packaging an application Inside a Java container for execution.
  • Live Redeploy
    • The vertex launcher has another big benefit, and this is the live redeploy Functionality.
    • During development it automatically, redeploys our application Upon any changes.
    • To enable live redeployment add the program, arguments as follows
      • --redeploy=**/*.class --launcher-class=io.vertx.core.Launcher
  • Vertex Docker -Fat Jar
    • The default standard To deploy an application in the cloud is to bundle it and deploy on a docker container.
    • We need to bundle a vertex fat jar into docker container to run vertex application from docker.
    • We also need a Google jib plug-in To bundle a docker Container during the build.
    • An example of fat jar Execution using docker file is given In following docker file.
  • Vertex Docker Jib
    • Google Jib Is used to bundle our application into a docker container.
    • Jib Is open source and can be found on Github.
    • Jib is fast, Reproducible and Demonless

      • Deploy your changes fast. Jib separates your application into multiple layers, splitting dependencies from classes. Now you don’t have to wait for Docker to rebuild your entire Java application - just deploy the layers that changed.

      • Rebuilding your container image with the same contents always generates the same image. Never trigger an unnecessary update again.

      • Demonless means that it can build Docker container Even without running a docker demon.Reduce your CLI dependencies. Build your Docker image from within Maven or Gradle and push to any registry of your choice. No more writing Dockerfiles and calling docker build/push.
      • No docker files are needed To create a container.
      • Integration happens through a maven or gradle plugin.
  • References

Comments

Post a Comment