I am afraid we may have boxed ourselves in a corner with SQLite. It seems we have run out of indexing capability: our latest folder for the database is named “ff”…
This instance of Orthanc is not receiving anymore data, which is ok as we have another platform taking over. However, the issue is that we cannot access the data through the REST API.
A curl to retrieve a study results in:
{
“HttpError” : “Internal Server Error”,
“HttpStatus” : 500,
“Message” : “SQLite: Cannot step over a cached statement”,
“Method” : “GET”,
“OrthancError” : “SQLite: Cannot step over a cached statement”,
I have managed to find the error management portion of the code, but I cannot make much of it. I am not an SQLite users either. My hunch is that the full database and the above error are connected. But I am not sure what mechanism is taking place behind the scene and so cannot see an escape route.
The name “ff” has nothing to do with your issue: As the filenames are taken randomly from the 128-bit UUID domain (https://en.wikipedia.org/wiki/Universally_unique_identifier), it is perfectly normal that some files start with “ff”. Your database is not full (except of course if there is no space left on your filesystem).
This error might indicate that you have two Orthanc servers running on the same SQLite database, which is not allowed (as SQLite database can only be used by one single software at a time).
Regarding the two Orthanc instances, they run on two different filesystems and I thought it would be sufficient to separate the databases. What mechanisms should I use to ensure separation on the same headnode, if possible?
A SQLite database can only be used by a single instance of Orthanc.
If you want “N” instances of Orthanc to access the same database, you’ll have to use either the PostgreSQL plugin or the MySQL plugin.
Very importantly, for the time being, the only possible configuration is to have 1 “Orthanc writer” with N “Orthanc readers”, even if PostgreSQL/MySQL is used. This is explained in the Orthanc Book: https://book.orthanc-server.com/plugins/postgresql.html#locking
The most generic scenario (M writers and N readers accessing the same database) requires refactoring in the Orthanc core. We are looking for funding to implement this feature.