Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native TS: integration-tests/quartz leaves hanging processes #28114

Closed
Karm opened this issue Sep 21, 2022 · 8 comments · Fixed by #28118
Closed

Native TS: integration-tests/quartz leaves hanging processes #28114

Karm opened this issue Sep 21, 2022 · 8 comments · Fixed by #28118

Comments

@Karm
Copy link
Member

Karm commented Sep 21, 2022

Describe the bug

It seems that the TS leaves hanging Quartz runner processes. At least when executed with builder image and in native mode. It becomes apparent on a system that is not re-provisioned for each TS run, e.g.:

tester    120723  0.0  1.4 5122972 360856 ?      Sl   Aug31  15:15 /home/tester/quarkus/integration-tests/quartz/target/quarkus-integration-test-quartz-2.7.6.Final-runner -Dquarkus.http.port=8081 -Dquarkus.http.ssl-port=8444 -Dtest.url=http://localhost:8081 -Dquarkus.log.file.path=/home/tester/quarkus/integration-tests/quartz/target/quarkus.log -Dquarkus.log.file.enable=true
tester    269017  0.0  1.4 5122972 347316 ?      Sl   Sep01  14:44 /home/tester/quarkus/integration-tests/quartz/target/quarkus-integration-test-quartz-2.7.6.Final-runner -Dquarkus.http.port=8081 -Dquarkus.http.ssl-port=8444 -Dtest.url=http://localhost:8081 -Dquarkus.log.file.path=/home/tester/quarkus/integration-tests/quartz/target/quarkus.log -Dquarkus.log.file.enable=true
tester    456872  0.0  1.4 4464060 347228 ?      Sl   Sep19   1:04 /home/tester/quarkus/integration-tests/quartz/target/quarkus-integration-test-quartz-2.13.0.CR1-runner -Dquarkus.http.port=8081 -Dquarkus.http.ssl-port=8444 -Dtest.url=http://localhost:8081 -Dquarkus.log.file.path=/home/tester/quarkus/integration-tests/quartz/target/quarkus.log -Dquarkus.log.file.enable=true
tester    

The good new is the process survived since August. The bad news is that this should not be happening.
I will take a look at what the Quartz TS does and why this happens unless someone well versed in Quartz beats me to it.

Expected behavior

TS does not leave any hanging processes.

Actual behavior

Quartz native executable runner left.

How to Reproduce?

#!/bin/sh
export CONTAINER_RUNTIME=podman
export JAVA_HOME="/usr/java/openjdk-11"
export PATH="${JAVA_HOME}/bin:${PATH}"
export BUILDER_IMAGE_WITHOUT_TAG=<mandrel builder image>
export BUILD_DISPLAY_NAME=<mandrel builder image tag>
export QUARKUS_VERSION=2.13.0.CR1
export QUARKUS_REPO=https://github.com/quarkusio/quarkus.git
export QUARKUS_MODULES="\
!bouncycastle-fips-jsse,\
!container-image/quarkus-standard-way,\
!devtools,\
!google-cloud-functions,\
!google-cloud-functions-http,\
!gradle,\
!hibernate-orm-panache-kotlin,\
!kotlin,\
!kotlin-serialization,\
!kubernetes-client,\
!kubernetes/maven-invoker-way,\
!maven,\
!mongodb-panache-kotlin,\
!mongodb-rest-data-panache,\
!rest-client-reactive-kotlin-serialization,\
!resteasy-reactive-kotlin,\
!smallrye-opentracing"

 ${CONTAINER_RUNTIME} pull ${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME}
 if [ "$?" -ne 0 ]; then
     echo There was a problem pulling the image ${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME}. We cannot proceed.
     exit 1
 fi
 ${CONTAINER_RUNTIME} run ${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME} --version
 if [ "$?" -ne 0 ]; then
     echo There was a problem running --version with  ${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME}. We cannot proceed.
     exit 1
 fi
 ${CONTAINER_RUNTIME} inspect ${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME}
 rm -rf quarkus
 git clone --quiet --depth 1 --branch ${QUARKUS_VERSION} ${QUARKUS_REPO}
 cd quarkus
 export MAVEN_OPTS="-Xmx5g -XX:MaxMetaspaceSize=4g"
 ./mvnw install -Dquickly
 ./mvnw verify -fae -f integration-tests/pom.xml -Dmaven.test.failure.ignore=true \
     -pl ${QUARKUS_MODULES} -Ddocker -Dnative \
     -Dquarkus.native.container-build=true \
     -Dquarkus.native.builder-image="${BUILDER_IMAGE_WITHOUT_TAG}:${BUILD_DISPLAY_NAME}" \
     -Dquarkus.native.container-runtime=${CONTAINER_RUNTIME} \
     -Dquarkus.native.native-image-xmx=10g

Output of uname -a or ver

Linux amd64

Output of java -version

Temurin-11.0.15+10

GraalVM version (if different from Java)

22.3 dev, Git head: 4407306f2505

Quarkus version or git rev

2.13.0.CR1, 2.7.6.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

@Karm Karm self-assigned this Sep 21, 2022
@quarkus-bot quarkus-bot bot added area/kotlin area/kubernetes area/mandrel area/scheduler area/securepipeline issues related to ensure Quarkus can be used in a secure pipeline setups like FIPS or similar labels Sep 21, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented Sep 21, 2022

@Karm Karm changed the title Native test suite, Builder image: integration-tests/quartz leaves hanging processes Native TS: integration-tests/quartz leaves hanging processes Sep 21, 2022
@Karm Karm removed area/kotlin area/kubernetes area/securepipeline issues related to ensure Quarkus can be used in a secure pipeline setups like FIPS or similar labels Sep 21, 2022
@geoand
Copy link
Contributor

geoand commented Sep 21, 2022

I can confirm I see this. I'll check and see what is going on

@geoand
Copy link
Contributor

geoand commented Sep 21, 2022

#28118 takes care of it

@Karm
Copy link
Member Author

Karm commented Sep 21, 2022

I can reproduce it with the current main on my workstation too as:

$ C=5 while [ $C -ge 0 ];do ./mvnw verify -fae -f integration-tests/pom.xml -Dmaven.test.failure.ignore=true 
-pl quartz -Ddocker -Dnative -Dquarkus.native.container-build=true 
-Dquarkus.native.builder-image=<builder image> 
-Dquarkus.native.container-runtime=docker -Dquarkus.native.native-image-xmx=10g;let C=$C-1;done
$ ps aux | grep "quarkus.*quartz.*runner"
karm       48892  0.2  0.3 4032820 127580 pts/2  Sl   10:26   0:00 /home/karm/workspaceRH/quarkus/integration-tests/quartz/target/quarkus-integration-test-quartz-999-SNAPSHOT-runner -Dquarkus.http.port=8081 -Dquarkus.http.ssl-port=8444 -Dtest.url=http://localhost:8081 -Dquarkus.log.file.path=/home/karm/workspaceRH/quarkus/integration-tests/quartz/target/quarkus.log -Dquarkus.log.file.enable=true

@geoand
Copy link
Contributor

geoand commented Sep 21, 2022

Yup, there was an oversight in the test framework

@Karm
Copy link
Member Author

Karm commented Sep 21, 2022

#28118 takes care of it

Thanks @geoand , that was well within the under an hour SLA 😃 😃 😃

@geoand
Copy link
Contributor

geoand commented Sep 21, 2022

😆

geoand added a commit to geoand/quarkus that referenced this issue Sep 21, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a certain amount of time for the scheduler
to shutdown.

Relates to quarkusio#28114
@geoand
Copy link
Contributor

geoand commented Sep 21, 2022

#28119 is also related

geoand added a commit that referenced this issue Sep 21, 2022
Ensure that @QuarkusIntegrationTest does not leave dangling processes
@quarkus-bot quarkus-bot bot added this to the 2.14 - main milestone Sep 21, 2022
geoand added a commit to geoand/quarkus that referenced this issue Sep 23, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114
geoand added a commit to geoand/quarkus that referenced this issue Sep 23, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114
geoand added a commit to geoand/quarkus that referenced this issue Sep 23, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114
geoand added a commit to geoand/quarkus that referenced this issue Sep 26, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
geoand added a commit to geoand/quarkus that referenced this issue Sep 26, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
geoand added a commit to geoand/quarkus that referenced this issue Sep 26, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
@gsmet gsmet modified the milestones: 2.14 - main, 2.13.1.Final Sep 30, 2022
gsmet pushed a commit to gsmet/quarkus that referenced this issue Oct 3, 2022
igorregis pushed a commit to igorregis/quarkus that referenced this issue Oct 16, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
igorregis pushed a commit to igorregis/quarkus that referenced this issue Oct 16, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
igorregis pushed a commit to igorregis/quarkus that referenced this issue Oct 16, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
igorregis pushed a commit to igorregis/quarkus that referenced this issue Oct 17, 2022
The Quartz scheduler shutdown seems like it
can block indefinitely if there is an exception
in a yet to be completed job.
To guard against this, we ensure that we only
wait a configurable amount of time for the scheduler
to shut down.

This is a breaking change because previously we waited
indefinitely.

Relates to quarkusio#28114

Co-authored-by: Manyanda Chitimbo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants