Postgres - Saving Modalities to DB

[ja...@binary.com.au]

Hi Orthanc Team,

We use Orthanc with Postgres Plugin and DicomModalitiesInDatabase set to true.  We use the osimis/orthanc docker image.

Recently, I have noticed that when I restart our systems for an update via docker-compose down && docker-compose up, our systems loose the stored modalities.  I have tested it not using the Postgres database and the modalities are persisted across restarts.  It appears to be restricted to the Postgres plugin.

Attached is a docker-compose.yml file that replicates the issue. Note that the Postgres database is persisted using a named docker volume.

To replicate:

1. using the attached docker-compose.yml - run docker-compose up -d
2. Create a modality 
3. curl --location --request PUT http://localhost:8042/modalities/test' --header 'Content-Type: application/json' --data-raw '{"AET":"test","Host": "localhost","Port": "4242"}'
4. Verify the modality was created correctly - curl --location --request GET 'http://localhost:8042/modalities/test'
5. Stop Docker & Postgres - docker-compose down
6. Restart the stack - docker-compose up -d
7. Check the modality configuration curl --location --request GET http://localhost:8042/modalities/test' - which returns a 404.

Thanks again for your work!

James

[Sébastien Jodogne]

Hello,

If I start Orthanc using Docker, and if I use the PostgreSQL database that is running as a service on my computer (without Docker), I cannot reproduce your issue. The modality is properly restored if I stop, then restart Orthanc.

For reference, here is how I start Orthanc:

$ docker run --rm -t -i -p 8042:8042 -e ORTHANC__DICOM_MODALITIES_IN_DATABASE=true -e ORTHANC__POSTGRESQL__ENABLE_INDEX=true -e ORTHANC__POSTGRESQL__HOST=192.168.0.17 -e ORTHANC__POSTGRESQL__DATABASE=orthanctest -e ORTHANC__POSTGRESQL__USERNAME=postgres -e ORTHANC__POSTGRESQL__PASSWORD=postgres osimis/orthanc:21.6.0

So, I guess that the issue is with how Docker Compose starts the "postgres:13.2-alpine" image: Visibly, you should map more volumes than just "/var/lib/postgresql/data".

HTH,

Sébastien-

[James Manners]

Hi Sebastian,

Thanks very much for the quick response. 

I should have added that as a test I added an instance to the stack using the same docker-compose.yml and restarted the stack and the instance was persisted, but strangely the modality wasn’t. 

I will review the volumes mapping for Postgres but was intrigued by the difference in persistence between modalities and instances. 

James

--
You received this message because you are subscribed to the Google Groups "Orthanc Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orthanc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/831e9543-9f37-4732-a4fd-836e2d20f1dan%40googlegroups.com.

--

James Manners • Director Suite 3, Level 2, 10 Queens Road, Melbourne, Victoria 3004, Australia T:  03 9017 5230 M:  0422 973 235 E:  ja...@binary.com.au W:  binary.com.au

[ja...@binary.com.au]

Hi Sébastien,

I spent some more time investigating this.

The problem only occurs after stopping and restarting both Orthanc & Postgres.

If I use the osimis/orthanc:21.2.0 container, the problem does not occur. 

If I use the 21.4.0 container, which is the first with the PostgreSQL v4 plugin the problem occurs.

What I have noticed, is that using the 21.2.0 image, the modalities are stored in the serverproperties table.  With this version, the server UUID remains the same after both containers are restarted.

However, with 21.4.0, the server UUID is different after the restart.  I can see that the old modalities are still stored in the table, but Orthanc is using a new UUID and hence when the modalities are read from the database, they don't exist.

It appears that with 21.4.0 & the latest Postgres Plugin, the server UUID changes after restarting both the Orthanc container and the database container.

I hope that helps. Let me know if there is anything more I can do to help you replicate it.

Cheers,

James

[Sébastien Jodogne]

Hello James,

Oh, ok, I got it: You're looking for the "DatabaseServerIdentifier" global configuration option that was introduced in Orthanc 1.9.2:

https://hg.orthanc-server.com/orthanc/file/Orthanc-1.9.3/OrthancServer/Resources/Configuration.json#l782

Quoting the documentation:

  // Arbitrary identifier of this Orthanc server when storing its
  // global properties if a custom index plugin is used. This
  // identifier is only useful in the case of multiple
  // readers/writers, in order to avoid collisions between multiple
  // Orthanc servers. If unset, this identifier is taken as a SHA-1
  // hash derived from the MAC adddresses of the network interfaces,
  // and from the AET and TCP ports used by Orthanc. Manually setting
  // this option is needed in Docker/Kubernetes environments. (new in
  // Orthanc 1.9.2)
  /**
     "DatabaseServerIdentifier" : "Orthanc1",
  **/

In my previous answer using Docker (and not Docker Compose), Docker was visibly reusing the same MAC address for its network interface, which explains why I hadn't been able to reproduce the issue.

HTH,

Sébastien-

[ja...@binary.com.au]

Ah ha! Thank you for that. I missed that config option.

Thanks again very much for helping out so quickly.

James