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

Execute the MongoDB Connection Health Check on Startup #45482

Closed
Inithron opened this issue Jan 9, 2025 · 6 comments · Fixed by #45523
Closed

Execute the MongoDB Connection Health Check on Startup #45482

Inithron opened this issue Jan 9, 2025 · 6 comments · Fixed by #45523
Labels
area/health kind/bug Something isn't working
Milestone

Comments

@Inithron
Copy link

Inithron commented Jan 9, 2025

Description

It would be great if the MongoDB Connection Health Check could be improved.

Current behavior

After startup following health check is displayed:

{
    "status": "UP",
    "checks": [
        {
            "name": "MongoDB connection health check",
            "status": "UP"
        }
    ]
}

But this status is misleading / wrong. Even if no database is available, the status is UP. Only when the application tries to store the first message in the DB, the status goes to down:

{
    "status": "DOWN",
    "checks": [
        {
            "name": "MongoDB connection health check",
            "status": "DOWN",
            "data": {
                "<default>": "KO, reason: Timed out while waiting for a server that matches ReadPreferenceServerSelector{readPreference=primary}. Client view of cluster state is {type=UNKNOWN, servers=[{address=localhost:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused: no further information}}]",
                "<default-reactive>": "KO, reason: null"
            }
        }
    ]
}

Improvement

It would be great, if the connection to the DB would be checked on startup and not when the application tries to store the first message in the DB.

Benefit

With this changed approach the pod in Kubernetes would never get green if there is a wrong connection string or the DB is down.

Implementation ideas

No response

Copy link

quarkus-bot bot commented Jan 9, 2025

/cc @geoand (kubernetes), @iocanel (kubernetes), @jmartisk (health), @loicmathieu (mongodb), @xstefank (health)

@geoand
Copy link
Contributor

geoand commented Jan 9, 2025

Makes sense IMO

@geoand
Copy link
Contributor

geoand commented Jan 10, 2025

Looking at the code, it should work as expected.

What version of Quarkus are you using?

@geoand geoand added the triage/needs-feedback We are waiting for feedback. label Jan 10, 2025
@Inithron
Copy link
Author

Inithron commented Jan 12, 2025

I am using 3.17.6
Here is a small reproducer with a unit tests showing the mentioned behavior:

reproducer-for-45482.zip

@geoand geoand removed the triage/needs-feedback We are waiting for feedback. label Jan 13, 2025
@geoand
Copy link
Contributor

geoand commented Jan 13, 2025

Thanks!

@geoand
Copy link
Contributor

geoand commented Jan 13, 2025

#45523 fixes the issue

@geoand geoand added kind/bug Something isn't working and removed kind/enhancement New feature or request area/smallrye area/mongodb area/kubernetes labels Jan 13, 2025
geoand added a commit that referenced this issue Jan 13, 2025
@quarkus-bot quarkus-bot bot added this to the 3.18 - main milestone Jan 13, 2025
@gsmet gsmet modified the milestones: 3.18 - main, 3.17.7 Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/health kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants