changeset 4986:a25e74fad379

todo
author Alain Mazy <am@osimis.io>
date Tue, 26 Apr 2022 16:14:49 +0200
parents c767035fff77
children 48b53ac404d9 8fba26292a9f
files TODO
diffstat 1 files changed, 15 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/TODO	Mon Apr 25 19:17:28 2022 +0200
+++ b/TODO	Tue Apr 26 16:14:49 2022 +0200
@@ -126,6 +126,8 @@
   DicomImageDecoder
 * Strict hierarchical C-FIND:
   https://groups.google.com/d/msg/orthanc-users/VBHpeGVSNKM/tkaVvjWFBwAJ
+* report DIMSE error codes in Rest API and job status for /store /query /move /retrieve
+* Log outgoing C-Find queries
 
 ---------
 Long-term
@@ -162,6 +164,19 @@
     - all computed counters at series/study/patient level
     - RequestAttributesSequence (sequence that must be included in all DicomWeb QIDO-RS for series)
 
+* Long-shot & not sure it is even feasible at all: try to reduce memory usage by implementing streaming
+  when receiving DICOM instances from the Rest API or from DICOM and store files directly to disk as they
+  are received.  Note that this would likely require rewriting large parts of Orthanc.  Note sure that 
+  would be compatible with Transcoding.
+  Use case: receiving 10 1GB instances in parallel can consume up to 20 GB
+  Alternative option 1: write an "external application/plugin" that would take care of these receptions, write the
+  file at the right place and send a signal to Orthanc to "adopt" the file.
+  Alternative option 2: declare a memory resource (X GB) that is available for reception.  Every time
+  Orthanc starts receiving a file, it reserves the memory or twice the memory (through a Semaphore)
+  if no memory is available, it waits and possibly timeouts returning a 503 or DIMSE A700 (out of resources).
+  This would at least protect from "out of memory" crashes.
+
+
 ========
 Database
 ========