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

Hetionet Browser is down #49

Open
Travis-Barton opened this issue Oct 21, 2022 · 7 comments
Open

Hetionet Browser is down #49

Travis-Barton opened this issue Oct 21, 2022 · 7 comments

Comments

@Travis-Barton
Copy link

When trying to connect to: https://neo4j.het.io/browser/

I get the following message:
Screen Shot 2022-10-21 at 1 37 45 PM

Which is new, I've been querying it for several days now without problems. Any idea why it suddenly needs a username/password?

@dhimmel
Copy link
Member

dhimmel commented Oct 22, 2022

Ah yes I see:

Database access not available. Please use :server connect to establish connection. There's a graph waiting for you.

It's probably the case that some part of the Neo4j instance is down but the part that returns the website is alive. Hence, you get the website without the database.

Let me tag @falquaddoomi. Perhaps we can add a health check that does a simple cypher query, to ensure the database is actually alive.

@falquaddoomi
Copy link

So, I've restarted all the VMs and the managed database associated with the project, which seems to have fixed things for now. That was likely more than what was necessary to fix this issue, so I'll do some poking around to figure out what actually needs to be restarted when this database issue comes up. @dhimmel, that's a good idea about issuing a real query as the health check -- right now it just checks that the neo4j browser UI is accessible, which apparently isn't enough to determine that the service is working. I'll report in this issue once the health check is modified and I've verified that it stops this specific issue.

Longer-term, I'll carve out some time to investigate migrating to neo4j 4.x (right now we're one 3.5.12). I'll also continue to investigate right-sizing the hardware so the container doesn't have to be restarted at all, let alone every few days as it is now.

@Travis-Barton
Copy link
Author

The browser is down again.

@dhimmel
Copy link
Member

dhimmel commented Oct 31, 2022

The browser is down again.

Argh! Thanks for the notification.

I'll carve out some time to investigate migrating to neo4j 4.x

I'll try to post an issue soon with the main things to be aware of for the upgrade to organize my thoughts from #33

I'll also continue to investigate right-sizing the hardware so the container doesn't have to be restarted at all

I suspect there's some sort of memory leak such that even the largest container might eventually break. It's also possible some users are submitting queries that end up exploding the instance.

@dhimmel
Copy link
Member

dhimmel commented Oct 4, 2024

@falquaddoomi https://neo4j.het.io/browser/ is down again. I see the VM on Google Compute Engine, but not sure what the process is to restart it.

@falquaddoomi
Copy link

Hey @dhimmel, sorry for the delay. It might be an SSL issue; http://neo4j.het.io/browser/ seems to work fine for me, but the HTTPS version is stalling indefinitely. Still investigating; I'll keep you posted here.

Regarding restarting the VM, if you do want to restart the entire thing versus just the running services, you can use the "Reset" button at the top of that page you linked. AFAIK the stack should come back up on its own after a reboot, but if it doesn't I can SSH into the machine and try to bring it up.

@falquaddoomi
Copy link

@dhimmel Well, I just restarted the neo4j server container on that VM, hetionet-container, and that appeared to resolve whatever was going on with the HTTPS interface. For your reference, you can SSH into the machine and then run docker restart hetionet-container.

I recommend tailing the logs right after you do that via docker logs -f hetionet-container to see if things look reasonable. The last line you should see before it starts serving requests is something like:
2024-10-04 18:04:26.596+0000 INFO Remote interface available at http://localhost:7474/

Feel free to ping me if things go off the rails again and I can reboot it and/or debug further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants