Newer versions of MariaDB are not working anymore

Using latest pull of orthanc-databases and orthanc-1.12.10. I have been using for quite some time for indexing and now it’s completely stuck:

I0210 03:26:48.635340 HTTP-0 Toolbox.cpp:2782] (http) POST /tools/find
W0210 03:26:48.646378 HTTP-0 ResourceFinder.cpp:494] ResourceFinder: “Limit” is larger than LimitFindResults/LimitFindInstances configurations, using limit from the configuration file
I0210 03:26:48.656950 HTTP-0 mysql-index:/MySQLTransaction.cpp:63] An active MySQL transaction was dismissed
E0210 03:26:48.657899 HTTP-0 mysql-index:/DatabaseBackendAdapterV4.cpp:1415] Exception in database back-end: Internal error
I0210 03:26:48.658050 HTTP-0 mysql-index:/DatabaseManager.cpp:257] Cannot rollback a non-existing transaction
E0210 03:26:48.658088 HTTP-0 mysql-index:/DatabaseBackendAdapterV4.cpp:1415] Exception in database back-end: Bad sequence of calls
I0210 03:26:48.658155 HTTP-0 StatelessDatabaseOperations.cpp:393] Cannot rollback transaction: Bad sequence of calls

No other operation will work. Now my indexes ar trapped in MySQL database and I can’t migrate to anything else.

Tried starting a new PostgreSQL but it won’t import on it’s own from the storage area. The python script doesn’t recognize those as DICOM files.

Is there a quick way of bringing back on-line this?

Thank you

Hi,

Have you tried re-installing the previous versions of Orthanc and the MySQL plugin ?

What exact version ?

What about sharing more details of what happens ?

Were you using StorageCompression before ?

In general, read this before posting.

Best regards,

Alain.

The mainline version. It’s like git pull, last, no tags. I am compiling it locally usually without any issues. The previous version I had did not work anymore either so it’s why I thought a new version may solve the issue.

There is a recent MySQL/MariaDB security update that fiddled exactly with those ‘transaction’ order things so that may be the actual problem.

Recompiling / using an older version would not work unless i backtrack all mariadb libs (I think). I will try that on an old server and see if I can move them to the new one.

PostgreSQL is really not an option, I just wanted to see if it is working.
I do not use compression.
The server seems to have connected to the database and was ready to respond to queries and no errors were thrown. However, no old studies were being processed. I suppose I need to use Indexing Plugin I saw earlier this morning. I never used it so I didn’t know about it.

This is the query that is being first executed:

T0210 11:12:51.043708 HTTP-0 mysql-index:/MySQLDatabase.cpp:523] MySQL: START TRANSACTION READ ONLY
T0210 11:12:51.044390 HTTP-0 OrthancPlugins.cpp:6630] (plugins) Calling service 40 from plugin “/usr/local/share/orthanc/plugins/libOrthancMySQLIndex.so”
T0210 11:12:51.044859 HTTP-0 mysql-index:/MySQLStatement.cpp:371] Preparing MySQL statement: WITH Lookup AS (SELECT studies.publicId, studies.internalId, ROW_NUMBER() OVER (ORDER BY studies.publicId) AS rowNumber FROM Resources AS studies INNER JOIN DicomIdentifiers t0 ON t0.id = studies.internalId AND t0.tagGroup = 8 AND t0.tagElement = 32 WHERE studies.resourceType = 1 AND t0.value = ? LIMIT 100) SELECT 1 AS c0_queryId, Lookup.internalId AS c1_internalId, Lookup.rowNumber AS c2_rowNumber, Lookup.publicId AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, NULL AS c6_int1, NULL AS c7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup UNION ALL SELECT 2 AS c0_queryId, Lookup.internalId AS c1_internalId, NULL AS c2_rowNumber, value AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, tagGroup AS c6_int1, tagElement AS c7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup INNER JOIN MainDicomTags ON MainDicomTags.id = Lookup.internalId UNION ALL SELECT 4 AS c0_queryId, Lookup.internalId AS c1_internalId, NULL AS c2_rowNumber, value AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, type AS c6_int1, 0 AS C7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup INNER JOIN Metadata ON Metadata.id = Lookup.internalId UNION ALL SELECT 5 AS c0_queryId, Lookup.internalId AS c1_internalId, NULL AS c2_rowNumber, label AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, NULL AS c6_int1, NULL AS c7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup INNER JOIN Labels ON Labels.id = Lookup.internalId UNION ALL SELECT 20 AS c0_queryId, Lookup.internalId AS c1_internalId, NULL AS c2_rowNumber, childLevel.publicId AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, NULL AS c6_int1, NULL AS c7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup INNER JOIN Resources childLevel ON Lookup.internalId = childLevel.parentId UNION ALL SELECT 11 AS c0_queryId, Lookup.internalId AS c1_internalId, NULL AS c2_rowNumber, parentLevel.publicId AS c3_string1, NULL AS c4_string2, NULL AS c5_string3, NULL AS c6_int1, NULL AS c7_int2, NULL AS c8_int3, NULL AS c9_big_int1, NULL AS c10_big_int2 FROM Lookup INNER JOIN Resources currentLevel ON currentLevel.internalId = Lookup.internalId INNER JOIN Resources parentLevel ON currentLevel.parentId = parentLevel.internalId ORDER BY c0_queryId, c2_rowNumber
I0210 11:12:51.055113 HTTP-0 mysql-index:/MySQLTransaction.cpp:63] An active MySQL transaction was dismissed
T0210 11:12:51.055136 HTTP-0 mysql-index:/MySQLDatabase.cpp:523] MySQL: ROLLBACK
E0210 11:12:51.055972 HTTP-0 mysql-index:/DatabaseBackendAdapterV4.cpp:1415] Exception in database back-end: Internal error
I0210 11:12:51.066706 HTTP-0 mysql-index:/DatabaseManager.cpp:257] Cannot rollback a non-existing transaction

Thank you, I hope the information was helpful.

Update:

Using PostgreSQL backend

I tried advanced-storage, complained that it doesn’t support key-value and queues and didn’t do anything.

I then went with good old Indexer plugin that is working, even if it’s duplicating data, at least it’s doing what it is supposed to do. However even if it stores the data in postgres, I think he is still trying to store it in SQLite (not a bad thing) But there is an error there also:

E0210 13:40:07.099735 7fd412fbd6c0 PluginsManager.cpp:155] SQLite: Cannot run a cached statement
E0210 13:40:07.158348 7fd412fbd6c0 PluginsManager.cpp:155] SQLite error code 8

At the end of the day, it seems to be reimporting old instances in the PostgreSQL database. However, there seems to be a bit of an issue with rest of the database backends (new).

LE:
sqlite-3.50.2-2.x86_64
sqlite-libs-3.50.2-2.x86_64
mariadb-connector-c-config-3.4.8-1.noarch
mariadb-common-10.11.15-3.noarch
mariadb-errmsg-10.11.15-3.noarch
mariadb-connector-c-3.4.8-1.x86_64
mariadb-10.11.15-3.x86_64
mariadb-server-10.11.15-3.x86_64
mariadb-connector-c-devel-3.4.8-1.x86_64
mariadb-devel-10.11.15-3.x86_64
mariadb-server-utils-10.11.15-3.noarch
mariadb-gssapi-server-10.11.15-3.x86_64
mariadb-cracklib-password-check-10.11.15-3.x86_64
mariadb-backup-10.11.15-3.x86_64
mariadb-client-utils-10.11.15-3.noarch
mariadb-connector-c-doc-3.4.8-1.noarch

You should give the last stable LSB version a try.