Orthanc auto deletes instances

Google Groups archive
1

Hi Author,
I encountered a case that Orthanc automatically deletes attachments after receiving dicom from the modality. I am using Orthanc 1.97 docker with plugins. I am also using Transfer Plugin to automate routing to another Orthanc. Here is the verbose log

I0107 01:51:28.373661 CommandDispatcher.cpp:917] (dicom) Finishing association with AET SA309 on IP 10.0.0.63: DUL Peer Requested Release
I0107 01:51:28.373692 CommandDispatcher.cpp:925] (dicom) Association Release with AET SA309 on IP 10.0.0.63
I0107 01:51:37.289082 CommandDispatcher.cpp:332] (dicom) Association Received from AET SA311 on IP 10.0.0.60
I0107 01:51:37.289329 main.cpp:318] Incoming connection from AET SA311 on IP 10.0.0.60, calling AET NETGATE1
I0107 01:51:37.289606 CommandDispatcher.cpp:663] (dicom) Association Acknowledged (Max Send PDV: 28660) to AET SA311 on IP 10.0.0.60
I0107 01:51:37.291940 main.cpp:352] Incoming Store request from AET SA311 on IP 10.0.0.60, calling AET NETGATE1
I0107 01:51:37.327289 FilesystemStorage.cpp:124] Creating attachment “d3626f73-e59e-4bbf-a78f-e5eaf8171075” of “DICOM” type (size: 3MB)
I0107 01:51:37.344274 OrthancPlugins.cpp:2688] (plugins) Plugin making REST GET call on URI /instances/6566e18b-0e4b0b0d-6a7e89b2-c429fed7-74b6bf3b (built-in API)
I0107 01:51:37.344412 PluginsManager.cpp:172] (plugins) New instance has been added to series d5e844d9-37e20783-6534a5d1-428da69f-05f7ae06, invalidating it
I0107 01:51:37.344529 ServerContext.cpp:624] New instance stored
I0107 01:51:37.345904 CommandDispatcher.cpp:917] (dicom) Finishing association with AET SA311 on IP 10.0.0.60: DUL Peer Requested Release
I0107 01:51:37.345928 CommandDispatcher.cpp:925] (dicom) Association Release with AET SA311 on IP 10.0.0.60
I0107 01:51:42.479805 CommandDispatcher.cpp:332] (dicom) Association Received from AET AWP1963791 on IP 10.0.0.45
I0107 01:51:42.480061 main.cpp:318] Incoming connection from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.480215 CommandDispatcher.cpp:663] (dicom) Association Acknowledged (Max Send PDV: 32756) to AET AWP1963791 on IP 10.0.0.45
I0107 01:51:42.630989 main.cpp:352] Incoming Store request from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.640926 FilesystemStorage.cpp:124] Creating attachment “8ce248fd-bf50-4339-818e-de5d40b804bd” of “DICOM” type (size: 1MB)
I0107 01:51:42.646620 FilesystemStorage.cpp:258] Deleting attachment “8ce248fd-bf50-4339-818e-de5d40b804bd” of type 1
I0107 01:51:42.647362 ServerContext.cpp:628] Already stored
I0107 01:51:42.649945 main.cpp:352] Incoming Store request from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.654632 FilesystemStorage.cpp:124] Creating attachment “173a547c-7b97-4a8f-9a38-367d59ccfb48” of “DICOM” type (size: 1MB)
I0107 01:51:42.658590 FilesystemStorage.cpp:258] Deleting attachment “173a547c-7b97-4a8f-9a38-367d59ccfb48” of type 1
I0107 01:51:42.659403 ServerContext.cpp:628] Already stored
I0107 01:51:42.660356 main.cpp:352] Incoming Store request from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.664899 FilesystemStorage.cpp:124] Creating attachment “61a8d9a0-791d-4de9-ac77-2f5e5554901b” of “DICOM” type (size: 1MB)
I0107 01:51:42.668410 FilesystemStorage.cpp:258] Deleting attachment “61a8d9a0-791d-4de9-ac77-2f5e5554901b” of type 1
I0107 01:51:42.669055 ServerContext.cpp:628] Already stored
I0107 01:51:42.676500 main.cpp:352] Incoming Store request from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.682023 FilesystemStorage.cpp:124] Creating attachment “5ffe752c-f592-408c-b30b-569fe8daca9b” of “DICOM” type (size: 1MB)
I0107 01:51:42.685933 FilesystemStorage.cpp:258] Deleting attachment “5ffe752c-f592-408c-b30b-569fe8daca9b” of type 1
I0107 01:51:42.686856 ServerContext.cpp:628] Already stored
I0107 01:51:42.687901 main.cpp:352] Incoming Store request from AET AWP1963791 on IP 10.0.0.45, calling AET NETGATE1
I0107 01:51:42.692786 FilesystemStorage.cpp:124] Creating attachment “2a1b47dd-7c02-4aa1-9d7d-f2cdc21aa9b0” of “DICOM” type (size: 1MB)
I0107 01:51:42.696276 FilesystemStorage.cpp:258] Deleting attachment “2a1b47dd-7c02-4aa1-9d7d-f2cdc21aa9b0” of type 1
I0107 01:51:42.697053 ServerContext.cpp:628] Already stored

Can you please help to tell me what is the scenario where Orthanc says “Deleting attachment” ? P/S I do NOT call any api delete or modify resource.

Thanks,
Chris

2

This is maybe Modality sends the same instances multiple times. I’ve review the code in ServerContext.cpp from line : 598 to line 62, if an instance has been saved before, the new same one will be deleted (if mode Overwrite is false).

3

Hello,

Indeed, this is because your modality sends the same DICOM multiple times, as indicated in the logs:

I0107 01:51:42.654632 FilesystemStorage.cpp:124] Creating attachment “173a547c-7b97-4a8f-9a38-367d59ccfb48” of “DICOM” type (size: 1MB)
I0107 01:51:42.658590 FilesystemStorage.cpp:258] Deleting attachment “173a547c-7b97-4a8f-9a38-367d59ccfb48” of type 1
I0107 01:51:42.659403 ServerContext.cpp:628] Already stored

When Orthanc receives the DICOM instance, it first stores it in the storage area. Secondly, if it detects that this instance is already present in the database, it removes the instance from the storage area. This is the “creating/deleting attachment” sequence you observe in the logs.

Sébastien-

4

Thank you Sebastien for your confirmation.