miracum / fhir-gateway

A thin layer between FHIR REST clients and resource processing pipelines.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problems with skipping FHIR-DB

cerbelding opened this issue · comments

When running the FHIR-GW without FHIR-DB (SPRING_DATASOURCE_URL set empty, SERVICES_PSQL_ENABLED set to false) the FHIR-GW does not start properly.
Instead it continously restarts every X seconds.

The Error Message vom Docker-Log includes:

org.springframework.context.ApplicationContextException: Unable to start web server; nested exception is org.springframework.boot.web.server.WebServerException: Unable to start embedded Tomcat

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'skipPattern' defined in class path resource [io/opentracing/contrib/spring/web/starter/SkipPatternAutoConfiguration.class]

Caused by: org.h2.jdbc.JdbcSQLNonTransientException: Unknown data type: "JSONB";

Is there anything else to do, when trying to run FHIR-GW without FHIR-DB?

commented

Thanks for input! SERVICES_PSQL_ENABLED is arguably a bit misleading, since while it stops resources from being stored in a postgres DB, the app still tries to initialize this very same DB anway.

Please try setting SPRING_SQL_INIT_MODE=never (v3.8.1 and later) or SPRING_SQL_INIT_ENABLED=false (v3.8.0 and earlier) to stop this from happening.

With

  • SPRING_DATASOURCE_URL:
  • SERVICES_PSQL_ENABLED: false
  • SPRING_SQL_INIT_ENABLED: false

it is still the same.

I'm using image harbor.miracum.org/miracum-etl/fhir-gateway:3.5.3

commented

I currently can't download the older image version -at least not fast enough - but running:

docker run --rm -it -p 8080:8080 -e SERVICES_PSQL_ENABLED=false -e SPRING_SQL_INIT_MODE=never ghcr.io/miracum/fhir-gateway:v3.8.2 # harbor.miracum.org/miracum-etl/fhir-gateway:v3.8.2

starts fine. Feel free to just update to a later version of the gateway if it resolves the issue.

Since updating to v3.8.2 it works for me. Thank you!

Maybe updating the deploy/docker-compose.yml to v3.8.2 instead of v3.3 would be good.