Hibernate-reactive: las pruebas dejaron de funcionar en el escritorio de Docker

Creado en 4 oct. 2020 · 23Comentarios · Fuente: hibernate/hibernate-reactive

No tengo idea de lo que está sucediendo aquí, pero parece haber coincidido con la actualización del escritorio Docker en Mac a la última versión:

Gradle Test Executor 2 > org.hibernate.reactive.FilterTest > testFilterCollectionFetch FAILED
    org.testcontainers.containers.ContainerLaunchException: Container startup failed
        at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
        at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
        at org.hibernate.reactive.containers.PostgreSQLDatabase.getJdbcUrl(PostgreSQLDatabase.java:39)
        at org.hibernate.reactive.containers.DatabaseConfiguration.getJdbcUrl(DatabaseConfiguration.java:78)
        at org.hibernate.reactive.BaseReactiveTest.constructConfiguration(BaseReactiveTest.java:88)
        at org.hibernate.reactive.FilterTest.constructConfiguration(FilterTest.java:26)

        Caused by:
        org.testcontainers.containers.ContainerFetchException: Can't get Docker image: RemoteDockerImage(imageName=postgres:13.0, imagePullPolicy=DefaultPullPolicy())
            at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1279)
            at org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:613)
            at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:320)
            ... 5 more

            Caused by:
            java.lang.IllegalStateException: Can not connect to Ryuk at localhost:32768
                at org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:176)
                at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:168)
                at org.testcontainers.LazyDockerClient.getDockerClient(LazyDockerClient.java:14)
                at org.testcontainers.LazyDockerClient.listImagesCmd(LazyDockerClient.java:12)
                at org.testcontainers.images.LocalImagesCache.maybeInitCache(LocalImagesCache.java:68)
                at org.testcontainers.images.LocalImagesCache.get(LocalImagesCache.java:32)
                at org.testcontainers.images.AbstractImagePullPolicy.shouldPull(AbstractImagePullPolicy.java:18)
                at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:59)
                at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:26)
                at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:20)
                at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:27)
                at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1277)
                ... 7 more

    java.lang.NullPointerException
        at org.hibernate.reactive.BaseReactiveTest.after(BaseReactiveTest.java:156)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at io.vertx.ext.unit.junit.VertxUnitRunner.invokeTestMethod(VertxUnitRunner.java:95)
        at io.vertx.ext.unit.junit.VertxUnitRunner.lambda$invokeExplosively$0(VertxUnitRunner.java:114)
        at io.vertx.ext.unit.impl.TestContextImpl.run(TestContextImpl.java:90)
        at io.vertx.ext.unit.junit.VertxUnitRunner.invokeExplosively(VertxUnitRunner.java:130)
        at io.vertx.ext.unit.junit.VertxUnitRunner.access$000(VertxUnitRunner.java:39)
        at io.vertx.ext.unit.junit.VertxUnitRunner$3.evaluate(VertxUnitRunner.java:217)
        at io.vertx.ext.unit.junit.Timeout$1.evaluate(Timeout.java:45)
        at org.junit.rules.RunRules.evaluate(RunRules.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
        at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
        at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
        at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
        at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
        at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
        at java.lang.Thread.run(Thread.java:748)

¿Alguna idea @Sanne , @DavideD ?

bug testing

Fuente

gavinking

Comentario más útil

El cambio a testcontainers 1.15.0-rc2 parece haberlo solucionado.

gavinking en 4 oct. 2020

👍3

Todos 23 comentarios

¿Qué es un Ryuk y por qué debería ejecutarse en localhost: 32768?

gavinking en 4 oct. 2020

Oh, espera, acabo de encontrar esto: https://github.com/testcontainers/testcontainers-java/issues/3241

gavinking en 4 oct. 2020

PosgreSQL lanzó recientemente la versión 13, así que reconfiguré nuestras imágenes de prueba para usar la imagen postgres:13.0 . ¿Parece que no puedes descargarlo?

Extraño, supuestamente no es diferente de buscar las versiones anteriores.

Sanne en 4 oct. 2020

PosgreSQL lanzó recientemente la versión 13, así que reconfiguré nuestras imágenes de prueba para usar la imagen postgres:13.0 . ¿Parece que no puedes descargarlo?

Creo, pero no estoy seguro, que ya lo tenía funcionando en Postgres 13 hasta que actualicé Docker.

gavinking en 4 oct. 2020

La primera vez que escucho acerca de Ryuk .. de las pocas referencias de documentos que encontré, parece que se supone que debe iniciarse un servidor local opcional.
Es responsable de obtener imágenes en nombre de Testcontainers, por lo que no tener un nuevo contenedor (como postgresql 13) desencadenaría esto.

Parece un error en Testcontainers.

¿Podría solucionarlo descargando el contenedor una vez manualmente?

tratar

docker run --rm -it --name HibernateTestingPGSQL \
    -e POSTGRES_USER=hreact -e POSTGRES_PASSWORD=hreact -e POSTGRES_DB=hreact \
    -p 5432:5432 postgres:13.0

Sanne en 4 oct. 2020

El cambio a testcontainers 1.15.0-rc2 parece haberlo solucionado.

gavinking en 4 oct. 2020

👍3

Frio.
Alternativamente: https://www.testcontainers.org/features/configuration/#disabling -ryuk

Sanne en 4 oct. 2020

👍1

Alternativamente: https://www.testcontainers.org/features/configuration/#disabling -ryuk

Sí, eso funcionó.

¿Existe una forma correcta de establecer una variable de entorno desde el script de Gradle?

gavinking en 4 oct. 2020

Aparentemente:

test {
    environment "TESTCONTAINERS_RYUK_DISABLED", "true"

gavinking en 4 oct. 2020

bien, eso debería hacerlo.

Por cierto, mantenga pulsado durante unos minutos :) la liberación se está ejecutando

Sanne en 4 oct. 2020

👍1

Lanzamiento hecho ... Haré las actualizaciones de Quarkus ahora.

Sanne en 4 oct. 2020

Lanzamiento hecho ... Haré las actualizaciones de Quarkus ahora.

¡Excelente!

gavinking en 4 oct. 2020

¿Sigue siendo un problema?

DavideD en 13 oct. 2020

Creo que el error sigue ahí, pero las únicas personas que lo van a experimentar son las personas que aún no tienen el dispositivo en su máquina local.

gavinking en 13 oct. 2020

Entonces, me pregunto si esto fue causado por la necesidad de actualizar la base de datos de prueba al migrar de Postgres 12 a 13.

Mira, tengo testcontainers.reuse.enable=true set, que quizás reutiliza la base de datos entre ejecuciones de prueba.

gavinking en 26 oct. 2020

¿No creo que _necesitamos_ estrictamente esa actualización a PostgreSQL 13?

AFAIR cuando lo actualicé, no necesité hacer ningún cambio relacionado, por lo que esperaría que todo funcione bien también en 12, a menos que se haya incluido una regresión mientras tanto, pero eso parece menos probable que tener algunos problemas con la ventana acoplable / contenedores de prueba.

Sanne en 26 oct. 2020

Tal vez intente revertir la configuración a 12 y vea.

Sanne en 26 oct. 2020

Estoy experimentando esto de nuevo :-(

Mira, tengo testcontainers.reuse.enable=true set, que quizás reutiliza la base de datos entre ejecuciones de prueba.

Lo puse en falso y no solucionó el problema.

gavinking en 6 nov. 2020

environment "TESTCONTAINERS_RYUK_DISABLED", "true"

Esto lo arregló de nuevo.

@Sanne ¿Crees que debería introducir este cambio en el script de Gradle?

gavinking en 6 nov. 2020

Claro, por que no. Parece ser una característica nueva, y hasta ahora estamos felices sin ella.

Sanne en 6 nov. 2020

Es responsable de obtener imágenes en nombre de Testcontainers, por lo que no tener un nuevo contenedor (como postgresql 13) desencadenaría esto.

En realidad, es responsable de cerrar los contenedores después de ejecutar las pruebas. Si mata la JVM, los ganchos de cierre no se ejecutarán y los contenedores continuarán ejecutándose, creando contenedores colgantes.
La variable de entorno está ahí para los sistemas CI donde no se puede usar Ryuk (por ejemplo, BitBucket Pipelines) pero garantizan la limpieza ellos mismos.

tl; dr: no deshabilite Ryuk;)

bsideup en 7 nov. 2020

Si mata la JVM, los ganchos de cierre no se ejecutarán y los contenedores continuarán ejecutándose, creando contenedores colgantes.

Bueno, TBH, siempre corro con testcontainers.reuse.enable=true , así que supongo que eso es lo que sucede de todos modos.

Y, a fin de cuentas, los contenedores colgantes son menos peores que mis pruebas simplemente que no se ejecutan. :-)

Pero claro, si esto se soluciona en 1.15 (que acaba de salir hace dos días, creo), entonces eso es genial, y en su lugar lo actualizaremos.

gavinking en 7 nov. 2020

¡Gracias por explicar eso @bsideup !

Sanne en 7 nov. 2020

¿Fue útil esta página

0 / 5 - 0 calificaciones

Temas relacionados

La actualización de la entidad asociada falla con UnsupportedOperationException usando Quarkus

Thomodachi · 15Comentarios

Mejora: integración con la anotación Spring @Transactional

yaakov-berkovitch · 16Comentarios

replicar HHH-14312

gavinking · 6Comentarios

exportación de esquema a través del controlador Vert.x en lugar de JDBC

aguibert · 28Comentarios

Cambie el nombre del proyecto a 'Hibernate Reactive'

Sanne · 12Comentarios