Translate

Mostrando las entradas con la etiqueta Vert.x. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Vert.x. Mostrar todas las entradas

viernes, 22 de octubre de 2021

Mutiny!

 



Si leen este blog, algo sabran de reactive programming y de quarkus, Mutiny! es el framework elegido por la gente de red hat para implementar reactive programming en quarkus.

Podemos usarlo en nuestros proyectos, sin necesidad de usar quarkus, es decir, de forma independiente. A la vez se acopla muy bien con vert.x. Y entre sus características, podemos nombrar que es un framework moderno, liviano y pequeño. 

Veamos un "hola mundo" : 

import io.smallrye.mutiny.Uni;


public class FirstProgram {


  public static void main(String[] args) {

    Uni.createFrom().item("hello")

      .onItem().transform(item -> item + " mutiny")

      .onItem().transform(String::toUpperCase)

      .subscribe().with(

        item -> System.out.println(">> " + item));

  }

}

Podemos ver como sigue los conceptos básicos de un framework reactive, es decir, tiene Observable, transformaciones y suscriptores.  Lo interesante es cómo se construye el mensaje. Describimos una tubería de procesamiento que toma un item, lo procesa y finalmente lo consume.

Primero, creamos un Uni, uno de los dos tipos con Multi que proporciona Mutiny. Un Uni es un flujo que emite un solo elemento o un error.

Aquí, creamos un Uni que emite el elemento "hello". Esta es la entrada de nuestro pipeline. Luego procesamos este item:

  • agregamos "mutiny", luego
  • lo convertimos en una cadena en mayúsculas.
  • Esto forma la parte de procesamiento de nuestra canalización, y luego finalmente nos suscribimos a la canalización.


Esta última parte es fundamental. Si no tiene un suscriptor final, no sucederá nada. Los tipos de mutiny son perezosos, lo que significa que debes suscribirte. Si no lo hace, el cálculo ni siquiera comenzará.

Si su programa no hace nada, tenemos que verificar que no se nos olvidó de suscribirnos.

Dejo link : https://smallrye.io/smallrye-mutiny/ 

jueves, 2 de julio de 2020

Proyecto Loom


Hasta hace medianamente poco el mundo era manejado mediante hilos o Thread. Era el modo por defecto para encarar aplicaciones concurrentes. Un desarrollador inicia un hilo de Java en el programa, y las tareas se asignan a este hilo para ser procesadas. Los subprocesos pueden realizar una variedad de tareas, como leer desde un archivo, escribir en una base de datos, recibir información de un usuario, etc.

Java facilita la creación de nuevos subprocesos, y los programas crean más subprocesos de los que la CPU puede procesar en paralelo. Digamos que tenemos una carretera de dos carriles (dos núcleos de una CPU), y 10 autos quieren usar la carretera al mismo tiempo. Naturalmente, esto no es posible, pero piense en cómo se maneja actualmente esta situación. Los semáforos son unidireccionales. Los semáforos permiten que un número controlado de automóviles ingresen a la carretera y hacen que el tráfico use la carretera de manera ordenada.

En computadoras, este es un planificador. El planificador asigna el hilo a un núcleo de CPU para ejecutarlo. En el mundo moderno del software, el sistema operativo cumple esta función de programar tareas (o subprocesos) en la CPU.

En Java, cada subproceso se asigna a un subproceso del sistema operativo por la JVM (casi todas las JVM hacen eso). Con los hilos superando en número a los núcleos de CPU, se asigna un montón de tiempo de CPU para programar los hilos en el núcleo. Si un subproceso pasa al estado de espera (por ejemplo, esperando que responda una llamada de la base de datos), el subproceso se marcará como en pausa y se asignará un subproceso separado al recurso de la CPU. Esto se llama cambio de contexto (aunque se requiere mucho más para hacerlo). Además, cada subproceso tiene algo de memoria asignada y el sistema operativo solo puede manejar un número limitado de subprocesos.

Considere una aplicación en la que todos los hilos están esperando que responda una base de datos. Aunque la computadora de la aplicación está esperando la base de datos, se están utilizando muchos recursos. Con el auge de las aplicaciones a escala web, este modelo de subprocesos puede convertirse en el principal cuello de botella para la aplicación.

Una solución es hacer uso de la programación reactiva. Brevemente, en lugar de crear subprocesos para cada tarea concurrente (y tareas de bloqueo), un subproceso dedicado (llamado bucle de eventos) examina todas las tareas que se asignan a subprocesos en un modelo no reactivo y procesa cada uno de ellos en el mismo Núcleo de la CPU. Por lo tanto, si una CPU tiene cuatro núcleos, puede haber múltiples bucles de eventos pero sin exceder el número de núcleos de CPU. Este enfoque resuelve el problema del cambio de contexto, pero introduce mucha complejidad en el programa mismo. Este tipo de programa también se escala mejor, que es una razón por la que la programación reactiva se ha vuelto muy popular en los últimos tiempos. Vert.x es una de esas bibliotecas que ayuda a los desarrolladores de Java a escribir código de manera reactiva.

Por lo tanto, el modelo de subprocesos por tarea es fácil de implementar pero no escalable. La programación reactiva es más escalable, pero la implementación es un poco más complicada. Un gráfico simple que representa la complejidad del programa frente a la escalabilidad del programa se vería así:



Lo que necesitamos es un punto óptimo como se menciona en el diagrama anterior (el punto verde), donde obtenemos una escala web con una complejidad mínima en la aplicación. Y ese es Project Loom. 

En lugar de asignar un subproceso del sistema operativo por subproceso Java (modelo JVM actual), Project Loom proporciona que múltiples subprocesos puedan ser ejecutados por un proceso del sistema operativo. Este enfoque proporciona un mejor uso (los subprocesos del sistema operativo siempre funcionan y no esperan) y mucho menos el cambio de contexto.

Project Loom provee concurrencia ligera de alto rendimiento y fácil de usar y nuevos modelos de programación en la plataforma Java.

El núcleo del Proyecto Loom involucra Continuations and Fibers. Pero esa historia será contada en otro post ...

Dejo link: 
https://developers.redhat.com/blog/2019/06/19/project-loom-lightweight-java-threads/

miércoles, 1 de julio de 2015

Vert.x construyendo aplicaciones reactivas en jvm

Vert.x es un framework java para la construcción de aplicaciones asíncronas, basadas en eventos y no bloqueantes. Esto significa que con Vert.x podemos obtener aplicaciones concurrentes con un mínimo de complejidad, y un hardware mínimo.

Para ser más explicativo se compara Vert.x con Node.js, por lo que se puede inferir que Vert.x fue pensado para ser concurrente, asíncrono y barato.

Otra ventaja de este framework es que es poliglota es decir podemos escribir aplicaciones en varios lenguajes, veamos un ejemplo:

Java:

public class Server extends AbstractVerticle {
  public void start() {
    vertx.createHttpServer().requestHandler(req -> {
      req.response()
        .putHeader("content-type", "text/plain")
        .end("Hello from Vert.x!");
    }).listen(8080);
  }
}

Ruby:

vertx.create_http_server().request_handler() { |req|
  req.response()
    .put_header("content-type", "text/plain")
    .end("Hello from Vert.x!")
}.listen(8080)

Javascript:

vertx.createHttpServer()
  .requestHandler(function (req) {
    req.response()
      .putHeader("content-type", "text/plain")
      .end("Hello from Vert.x!");
}).listen(8080);

Groovy:

vertx.createHttpServer().requestHandler({ req ->
  req.response()
    .putHeader("Content-Type", "text/html")
    .end("Hello from Vert.x!")
}).listen(8080)

Como vemos Vert.x proporciona una API en varios lenguajes que da soporte.

Dejo link:
http://vertx.io/
http://vertx.io/docs/