-
Notifications
You must be signed in to change notification settings - Fork 38
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
FAIRDataPoint unstable: breaking at the first restart #170
Comments
Hi @kburger , It seems like more people like @xiaofengleo are having this problem: #94 (comment) Is there any plan on fixing this major issue that prevents to reuse your service seriously in production? Not sure what's the goal of this "FAIRDataPoint" service and the "FAIRDataTeam", but seems like this is a service that should be easy to deploy at various places, to make the world more FAIR probably. Unfortunately the current stack relies on a database that can break and lose all data at any moment (which is the last thing you want when you are trying to build a trustful catalog of datasets.) |
Hi @vemonet, I'm sorry to hear about these issues. Unfortunately, I don't see the same behaviour for the demo instances we are running. The underlying systems are a bit different (running on Ubuntu with GraphDB), but that should not make that big of a difference. Can you provide me with some system specs? CPU and RAM for example? |
Hello, actually me and my team are having the same issue. After the first restart we get this exact same error and even by reinstalling the FDP we get the exact same error. We are working on a remote server VM running linux ubuntu 5.4.0 and last version of FDP with GraphDB. Docker-compose file was not changed, we changed only variables.scss to change icon and colours and application.yml to use our VM IP address (clientUrl: http://VM_IP:7070). |
Seeing similar status Using a basic docker compose file configured for port
instance:
clientUrl: http://localhost:8080
version: '3'
services:
fdp:
image: fairdata/fairdatapoint:1.17
volumes:
- ./application.yml:/fdp/application.yml:ro
fdp-client:
image: fairdata/fairdatapoint-client:1.17
ports:
- 8080:80
environment:
- FDP_HOST=fdp
mongo:
image: mongo:4.0.12 Steps to reproduce:
Here's some logging from
There's another issue that also looks very similar: However, that issue was (presumably) caused by Blazegraph, whereas we use the in-memory store (no persistence). |
Describe the bugs
A few months ago we started a FAIRDataPoint in "production", we logged in, created users, changed the weird default users/passwords manually, and we even added datasets metadata. It was "working" (the form to add metadata was really simple and did not help the user in adding dataset metadata, and the whole thing was not user-friendly to use, but it was at least showing some text fields for the datasets we entered!)
This was a few months ago, now when we go to the FAIRDataPoint we get greeted with
404
, see by yourself at https://fairdatapoint.semanticscience.org/The only error showing in the docker logs is:
I am trying to connect with the login/password I gave at the time, but I am getting bad login, and I can't reset the password
To Reproduce
Steps to reproduce the behavior:
404
on the main pageExpected behavior
Multiple things should be improved to make the FAIRDataPoint more stable and production-ready:
albert.einstein
user/password, this is really bad practice for service that are expected to go to productions at multiple places. This should be defined as environment variables at the start of the docker-compose (like for most services with login). So that the admin can at least reconnectContext
Please fill the following and eventually add additional information (e.g. about used storage in case that issue is storage-related):
Here is the
docker-compose.yml
we use:I already reported this issue when I started with FDP: #94
At the time I somehow managed to get it running by tweaking permissions of the Blazegraph volumes, but this wasn't a stable fix
Note that FDP can be deployed with multiple triplestores as backend, I used Blazegraph because this was the one pushed in the "production deployment" documentation: https://fairdatapoint.readthedocs.io/en/latest/deployment/production-deployment.html
So I was expecting blazegraph to be the triplestore working the best with FDP, but it does not seems to be the case
Maybe we should use another triplestore? But which one? It would be nice to have a clear idea of the exact stack that needs to be setup for production (with working persistent volumes)
The text was updated successfully, but these errors were encountered: