El lanzamiento de JobRunr 7.0 incluye soporte para subprocesos virtuales, habilitado de forma predeterminada, para aplicaciones que ejecutan JDK 21. Los subprocesos virtuales mejoran la concurrencia y reducen la sobrecarga asociada con los subprocesos tradicionales. Son particularmente beneficiosos para trabajos vinculados a E/S, ya que permiten a JobRunr manejar una cantidad más significativa de trabajos simultáneos. JobRunr 7.0 también mantiene compatibilidad con versiones anteriores de Java 8. JobRunr 7.1, una versión de mantenimiento reciente, ahora también admite subprocesos virtuales en el modo nativo GraalVM.
La implementación detecta si la aplicación se ejecuta en JDK 21 y cambia automáticamente a subprocesos virtuales sin requerir configuración manual por parte de los desarrolladores. Esta perfecta integración mejora el rendimiento de las aplicaciones con altas operaciones de E/S al duplicar la cantidad de trabajadores disponibles para realizar trabajos. Sin embargo, los subprocesos de la plataforma tradicional pueden ofrecer un mejor rendimiento para tareas que requieren un uso intensivo de la CPU, y JobRunr proporciona configuraciones para ajustar el uso de los subprocesos según las necesidades específicas de la aplicación. A pesar de la detección automática, los desarrolladores tienen la opción de configurar este comportamiento. Por ejemplo, si la carga de trabajo requiere un uso intensivo de la CPU en lugar de estar vinculada a E/S, los desarrolladores podrían encontrar que los subprocesos de la plataforma tradicional funcionan mejor. JobRunr permite ajustar estas configuraciones según las necesidades específicas de la aplicación.
org.jobrunr.background-job-server.thread-type=PlatformThreads #or org.jobrunr.background-job-server.thread-type=VirtualThreads Los desarrolladores pueden personalizar la configuración de los subprocesos virtuales a través de las propiedades de la aplicación o la API de JobRunr, lo que les brinda control sobre cómo se utilizan los subprocesos y garantiza un rendimiento óptimo adaptado a los requisitos de sus aplicaciones. Al igual que otros marcos que tienen por defecto JDK 21, esta actualización marca una mejora significativa en las capacidades de JobRunr, alineándolo con el último JDK 21. Además, los subprocesos virtuales son una optimización sustancial para la eficiencia del procesamiento de trabajos.
JobRunr 7.0 ha pasado de los UUID aleatorios tradicionales a los UUID basados en el tiempo, que son secuenciales e incorporan un componente de tiempo. Al utilizar UUID basados en el tiempo, JobRunr tiene como objetivo mejorar el rendimiento de la base de datos. Las bases de datos suelen indexar datos utilizando algoritmos de árbol B, y los UUID aleatorios pueden provocar ineficiencias en el almacenamiento y la consulta de datos. Los UUID basados en el tiempo proporcionan un patrón más secuencial que optimiza la estructura del árbol B, lo que lleva a inserciones y recuperaciones más rápidas. La naturaleza secuencial de los UUID basados en el tiempo reduce el tamaño de los índices en el disco, lo que ayuda aún más con el almacenamiento en caché y reduce las operaciones de E/S.
Otra mejora notable es la InMemoryStorageProvider clase. En el último webinar, el equipo de JobRunr aludió a esta mejora como parte de la mejora y optimización continua de JobRunr, incluso en aspectos tan fundamentales como cómo se almacenan y gestionan los trabajos en la memoria. En la versión 7.0, esta mejora está orientada al desarrollo y pruebas de casos de uso. Por ejemplo, reducir el intervalo de sondeo mejora la capacidad de probar trabajos. Un sondeo más rápido significa que los trabajos programados para las pruebas se procesan más rápido, lo que reduce el tiempo total de prueba.
Un buen ejemplo podrían ser las pruebas automatizadas durante las canalizaciones de CI/CD. El InMemoryStorageProvider El intervalo de sondeo se reduce a 200 milisegundos. De forma predeterminada, el intervalo de sondeo está establecido en 15 segundos. Sin embargo, se puede cambiar como argumento para BackgroundJobServer o mediante el uso de la propiedad en el marco correspondiente. Por ejemplo, configurando el intervalo de sondeo en Quarkus:
quarkus.jobrunr.background-job-server.poll-interval=15 La anotación de trabajo recurrente, @Recurring, ha pasado de paquetes específicos del marco, por ejemplo Spring, Quarkus y Micronaut, al paquete principal para eliminar la duplicación. Los desarrolladores ahora pueden excluir la configuración automática y utilizar el trabajo recurrente en su lugar. Además, la anotación ahora atribuye, paused y scheduleJobsSkippedDuringDowntimeahora usa enum en lugar de boolean. El paused El Estado permitirá un mayor control durante la redistribución de puestos de trabajo. Por ejemplo, si el paused El estado se establece en falso en el @Recurring anotación, no comenzará al volver a implementarse. Esto era diferente en la API anterior, donde el trabajo se iniciaba automáticamente al volver a implementarse.
El RedisStorageProvider y ElasticSearchStorageProvider También está previsto abandonar las clases. Durante el reciente seminario web, los autores señalaron que esto se debía a la falta de uso y a los altos costos de mantenimiento. JobRunr 7 será la última versión compatible con estos proveedores. Además, el StorageProvider La interfaz se ha actualizado y no es compatible con versiones anteriores, al igual que los Page y PageRequest clases, que no se utilizan a través de la clase Paging.
Otro cambio significativo para los usuarios está relacionado con el backend MongoDB, donde el controlador de base de datos se actualiza a la versión 5. Esta versión no es compatible con versiones anteriores, lo que requiere que los usuarios actualicen las versiones de sus controladores manualmente si usan Spring Boot 3.2, que todavía depende de una versión anterior. conductor.
Ronald Dehuysser, el creador de JobRunr, habló con InfoQ sobre este último lanzamiento y lo que hay en el horizonte para JobRunr, afirmando:
JobRunr v7, que presenta un motor renovado y mejoras significativas de rendimiento en todas las bases de datos, es nuestra mejor versión hasta el momento. Incluye UUID basados en el tiempo y la función SQL ‘seleccionar para actualizar omitir bloqueo’, las cuales minimizan los costos y el impacto ambiental. De cara al futuro, JobRunr v8 introducirá una programación de trabajos consciente del carbono, una característica diseñada para optimizar el uso de energía renovable y reducir las emisiones de CO2.
JobRunr 7 ofrece mejoras de rendimiento con el uso de subprocesos virtuales. La nueva API promete más control. Como ocurre con cualquier versión importante, los desarrolladores deben estar al tanto de los cambios importantes. El equipo de JobRunr 7 detalló los cambios en su blog de lanzamiento y seminario web.
