C-move requests timing out (sometimes) D: timeout of 10 seconds elapsed while waiting for C-MOVE Responses

[Drew Sims]

I'm trying to c-move images from a long term archive to another PACS (dcm4chee) system. I'm using orthanc to query and then c-move between the two asynchronously.

It is working, except sometimes the jobs will fail with a timeout part of the way through it and I have to restart them.

I have successfully moved a large amount of studies before these jobs fail so its not an association error with dicom AE titles etc being setup incorrectly.

When running with --verbose --trace-dicom here is the error its showing  before the job fails.

D: timeout of 10 seconds elapsed while waiting for C-MOVE Responses

E1116 15:44:35.364607 OrthancException.cpp:57] Error in the network protocol: DicomAssociation - C-MOVE to AET "VNARAD": DIMSE No data available (timeout in non-blocking mode)

Attached is my configuration.json file.

I've already changed both the  "DicomScpTimeout"   "DicomScuTimeout"  in the config file and i'm not sure where else to look.

Would appreciate any insight here.

[Alain Mazy]

Hi Drew,

So you mean you observe this 10 seconds timeout even while your DicomScpTimeout=600 and DicomScuTimeout=300 ?

That would mean that Orthanc does not take into account any of these timeouts in the scope of C-Move ?

Could you send me a sample query you use to trigger the C-Move ?

Best regards,

Alain.

--
You received this message because you are subscribed to the Google Groups "Orthanc Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orthanc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/7fb9818a-65d1-4de0-b19d-527882818e57n%40googlegroups.com.

[Drew Sims]

That is correct, even with those set it seems to be ignoring the configuration.

Here is the query, and request I sent for the c-move

curl -v http://localhost:8042/modalities/VNARAD/query POST -d '{"Level":"Study","Query":{"StudyDate":"20150801-20151015","PatientID":"","PatientName":""},"No

rmalize":false}'

curl --request POST --url http://localhost:8042/queries/991c5882-1d11-4f53-9f8e-85e2577fb80c/retrieve --data '{"TargetAet":"DCM4CHEE","Synchronous":false}'

Thanks,

Drew

[Alain Mazy]

Hi Drew,

I tried to step a bit in the code to investigate your issue.

I do observe that the DicomScuTimeout is passed correctly to the 

DIMSE_moveUser method at https://hg.orthanc-server.com/orthanc/file/7e1740813fa4/OrthancFramework/Sources/DicomNetworking/DicomControlUserConnection.cpp#l410

And the DCMTK log messages that you see "D: timeout of 10 seconds elapsed while waiting for C-MOVE Responses" comes from this line: https://github.com/DCMTK/dcmtk/blob/master/dcmnet/libsrc/dimmove.cc#L195

Therefore, it should be the "DicomScuTimeout" from the configuration file.

Hence my question: are you sure that the DicomScuTimeout is interpreted correctly in your configuration file ?  I noticed that it is defined twice to the same value in your config file but this should not harm.

Orthanc shall display the timeout at startup (in my case, DicomScuTimeout is 250:

I1117 17:38:28.869623 DicomAssociationParameters.cpp:375] (dicom) Default timeout for DICOM connections if Orthanc acts as SCU (client): 250 seconds (0 = no timeout)

and when opening a new association:

I1117 17:40:23.888202 DicomAssociation.cpp:274] (dicom) Opening a DICOM SCU connection without DICOM TLS from AET "ORTHANC-DEBUG" to AET "ORTHANC" on host 192.168.43.215:4242 (manufacturer: Generic, timeout: 250s)

Could you check your logs ?

Best regards,

Alain

To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/1b75ed6e-58c0-4534-a872-98533af0875cn%40googlegroups.com.

[Drew Sims]

Looking like having the Dicomscutimeout setting stated twice in the config file was causing an issue. 

With it in twice, I do not see the message for timeout setting on startup. Once I removed the second line, I am now seeing the correct 300 second timeout stated.

Will do more testing, but looks promising.

Thank you for the help on this one!

-Drew