Logging of DicomWeb Job WADO-RS

General
1

Hi all,

I’m using orthanc as a client to connect to a 3rd party dicom-web server. I’m issuing a wado-rs request for a single instance like so:

curl http://localhost:8042/dicom-web/servers/test/retrieve -X POST -d @- << EOF
{
  "Resources" : [
    {
      "Study" : "2.16.840.1.114362.1.12013697.24976369559.602424479.782.886",
      "Series" : "2.16.840.1.114362.1.12324993.26504912519.675550418.135.1"
    }
  ]
}

When I do this, the server is returning a response, but it is not properly receiving the instances - I get back the following:

{
   "NetworkUsageMB" : "5",
   "ReceivedInstancesCount" : "0"
}

and the patient is not stored into the orthanc database.

I’ve looked through the orthanc logs and I’ve not seen anything that would tell me why this is happening. It logs that it received the request successfully:

HTTP status code 200 in 22 ms after GET request on: http://host.docker.internal:60167/dicom-web/test/studies/2.16.840.1.114362.1.12013697.24976369559.602424479.782.886/series/2.16.840.1.114362.1.12324993.26504912519.675550418.135.1

and then it logs Job has completed with success.

Similarly, if I make the request via the orthanc web UI, it shows me a window with job information that shows the job was a success:

{
  "CompletionTime": "20250217T193223.685998",
  "Content": {
    "NetworkUsageMB": "6",
    "ReceivedInstancesCount": "0"
  },
  "CreationTime": "20250217T193223.184069",
  "EffectiveRuntime": 0.501,
  "ErrorCode": 0,
  "ErrorDescription": "Success",
  "ErrorDetails": "",
  "ID": "2f248620-5500-44d1-9ccc-9b74a9e93c99",
  "Priority": 0,
  "Progress": 100,
  "State": "Success",
  "Timestamp": "20250217T203618.566871",
  "Type": "DicomWebWadoRetrieveClient"
}

So it appears orthanc is using a jobs engine to perform the actual dicom-web wado call. And I’m wondering if the logs from those jobs go to a different location? Or if there’s some other reason that I’m not getting any specific logging that might indicate what the problem is, even if I turn all of the log categories to trace?

I’m sure there’s something wrong on my end, but without more information it’s hard for me to know what that is. :slight_smile:

Thanks in advance for any help!

2

I am not an Orthanc dev and it won’t help much but, from what I am seeing in the code, not seeing any error but not seeing any instance either could only happen if the server has replied with a multi-part message with… zero parts, which is not seemingly treated as an error (maybe it isn’t one?).

I also do not find a way to trace what is happening inside the DicomWeb plugin itself, apart from error conditions.

What I would suggest would be to perform the same request with another DicomWeb client such as the Python dicomweb-client ?

That could rule out any issue within Orthanc itself and, since I see a lot of logger.debug statements inside the dicomweb-client package, this could perhaps gives you more info on what is actually returned by this DicomWeb server, once you increase the log filtering level.

(Maybe the Orthanc devs will chime in with a magic DicomWebTraceMode flag that I missed, though!)

HTH

3

Hi, thanks for the response! And thanks for confirming that I’m on the right track and not missing anything obvious.

What I would suggest would be to perform the same request with another DicomWeb client such as the Python dicomweb-client ?

I forgot to mention in my original post that I did try exactly that, and the python dicom-web client accepts it.

(Maybe the Orthanc devs will chime in with a magic DicomWebTraceMode flag that I missed, though!)

That’s what I’m hoping for!

4

Hi,

There is no magic DICOMWeb trace mode.

Once Orthanc has received the 5/6 MB answer, the DICOMWeb plugin should try to split the parts and post each part to /instances → you should see that in the verbose logs. And it might show that the instances are not valid DICOM files.

If you don’t get anything useful from the verbose logs, I would suggest you to issue the same request with curl, directly to the DICOMWeb server and analyze the response received.

HTH,

Alain.

5

Hi, thanks for the response!

Once Orthanc has received the 5/6 MB answer, the DICOMWeb plugin should try to split the parts and post each part to /instances → you should see that in the verbose logs.

I’m not seeing that it called into /instances at all. Here’s everything I’m seeing in the logs, with trace-level logging turned on.

I would suggest you to issue the same request with curl, directly to the DICOMWeb server and analyze the response received.

I did that and it looks right to me, but I’m not a dicom parser. :slight_smile: Again, the python dicomweb-client seems to accept my responses just fine and is able to write them to disk. And if I pipe them to disk myself the dicom I end up with also seems valid.

6

link is broken