Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

In dcm4chee, DICOM objects which are transmitted out of the system (either as the result of a C-MOVE, or autoforwarding/routing) end up going through the Move SCU Service. This is a fairly robust process, but could use a few improvements when dealing with large studies, poor connections, and high volumes. Additionally, it would be nice to have some type of management interface for the transmission queue.

Ideas

This page is meant as a place to brainstorm about potential improvements to the Move SCU Service, and its operations. Please put any ideas you have here...

History

There is a funded project to do some development in this area. It is not clear whether this will happen in dcm4chee 2.x or dcm4chee 3.x, but it will happen in the October-November 2007 time frame.

Here are some forum and mailing list posts on this topic:

From the dcm4che-users mailing list on 6/18/2007

hi,

I'm wondering how the move service queue works.

I can see that upon scheduling image transfer a move order is created in this queue. These messages then are picked up and processed based upon retry intervals and some inner logic.

What I'm wondering about is:

  1. if the number of images scheduled for move is huge, the server has no chance of keeping up with retry schedule - how is this handled?
  2. what exactly are the conditions that lead to rescheduling an order - when is delivery accounted as unsuccessful?
  3. I also noticed, that upon server restart the "ScheduledMessageCount" number is reset to zero and even if the server was idle (not sending anything) before shutdown, it starts sending the data right after the start. What happens?
  4. Is it possible to reset the state of retries and make the server start sending data irrespective of the fact that maybe right now there is no study to be sent for which the retry schedule timeout has just expired?
  5. It happens to me, that when I load the server with a batch of data, the server is not able to process forwards simultaneously as the data arrive, the forwarding gets delayed and takes a very long time to finish, probably due to combination of not being able to send all the images at once and postponing all the queue to later retry time because of that. Is there a way to avoid this?

thanks a lot for even a partial response or tip, regards,
– peter

From the dcm4che Help forum on 8/31/2007

I have a setup where a DCM4CHEE server receives large images from a CR. The server uses the Forward Service to route to an offsite DCM4CHEE server and to several DICOM Workstations locally. Currently the link to the offsite is very slow and any CR Studies timeout when using the default DIMSETimeout. I was hoping that the SendPendingMoveResponse attribute would keep the connection between the two servers alive - but it doesn't seem to. Is this correct?

Also it looks like all Move requests end up on the same queue so sometimes the local Move requests end up being blocked by the failing offsite Moves. Question here is when a Move fails and a retry is scheduled does the retry request get put on the end of the queue?

  • No labels