Exporter Failures

    Greetings,


    I am using Conquest as a forwarder between 9 modalities and an offsite (3rd party) PACS system of a radiology group. Most of the time the ExportConverter works perfectly, but every once in a while, the transfer fails. It is my understanding that the failed images will be resent after 100 seconds or so (I have my retry set to 30 seconds). Is that true? Also, is there a way to view the queue of failed images that are waiting to be resent? I have attached my dicom.ini for reference. Here is the error from my logs:


    [EVDIROUTER01] 20180118 14:14:06 Retrieve: remote connection dropped after 804 images, 523 not sent
    [EVDIROUTER01] 20180118 14:14:06 ***preretrieve/forward xxx to: remote DICOM error


    Hi,


    Let me try and explain all items for you.


    ExportConverters = 1
    ExportConverter0 = forward SERIES to EVDIICRCMOD01 after 30


    This is fine, except that after 30 may be a bit short. If the series is not completely received after 30s, part of it would be lost.


    RetryForwardFailed = 50
    RetryDelay = 30
    MaximumDelayedFetchForwardRetries = 50
    You have default settings for: FailHoldOff = 60


    RetryForwardFailed is a binary flag, 1 is a good value. This is set to retry after single image failures. If the server ever sends a series with one image that the client really cannot handle this will be retried, so be careful. In you case the connection fails in the middle, so you need to set the flag indeed.


    You retry after 30 seconds, maximum 50 times. Again 30s may be a bit quick. It will retry at 30s, 2x30s, 3x30s. Any converter that fails is blocked for FailHoldOff seconds, assuming that the failure may be global so it is better to wait a bit.


    After a failure, a file ‘ExportFailures5678_0’ (where 5678=port number, 0=converter number) should appear. This file is binary but contains readable text for the export, such a FORWARD SERIES and the seriesinstanceUID.


    ForwardAssociationLevel = *
    ForwardAssociationCloseDelay = 5
    ForwardAssociationRefreshDelay = 600
    MaximumExportRetries = 50


    These settings relate to forwarding per image, which you do not use. The '*' is wrong, the default is SERIES, forwarding connections are kept open while image of the same SERIES are recieved for speed. The other settings are fine. As your FORWARD SERIES exports are queued, which cannot fail, the MaximumExportRetries flag has no effect.


    Hope this helps.


    Marcel

    Ok,


    That is what I thought. I guess my automatic retries are still not working. Here is an example:


    Code
    20180125 09:24:13 Sending file : c:\dicomserver\data\001851607\1.3.12.2.1107.5.1.4.86286.30000018012514412134300010790_0605_000069_15168973175b02.dcm20180125 09:24:13 Image Loaded from Read Ahead Thread, returning TRUE20180125 09:24:13 ReadAheadThread: readahead > 007620180125 09:24:13 FreeStore Left 71168 on c:\20180125 09:24:13 Written file: c:\dicomserver\data\001819078\1.3.12.2.1107.5.1.4.95193.30000018012514292967600000859_0005_000032_15168974535ef9.dcm20180125 09:24:13 Protocol error 0 in PDU:Read20180125 09:24:13 Retrieve: remote connection dropped after 68 images, 20 not sent


    I never again can find an attempt to send the file 'c:\dicomserver\data\001851607\1.3.12.2.1107.5.1.4.86286.30000018012514412134300010790_0605_000069_15168973175b02.dcm' when I search the log, even 2 hours later.



    Any ideas you can give me, I would really appreciate it.

    Hi,


    the error you report occurs on the C-STORE connection, is there any evidenence of a corresponding error on the C-MOVE connection that is initiated by the "forward series" queue? It should look like something starting with "***preretrieve/forward ...". It may be that the error is not properly reported back and that could explain the failure to retry.


    Marcel

    Yeah, I am sorry, I didn't paste that line. Here in another example from today. The first line is the attempt to send the file and the last is the error. the '20180126 10:44:12 ***preretrieve/forward xxx to: remote DICOM error' line also appears in my PacsTrouble.log


    Hi,


    indeed a hangup condition during a C-MOVE does not trigger a retry:


    OperatorConsole.printf("***preretrieve/forward xxx to: remote DICOM error\n");
    NonDestructiveDumpDICOMObject(&DCOR);
    rc = 1; // remote DICOM error: NO retry FOR NOW
    goto EXIT;


    If you are in linux you can change the line to rc = 2 to enable retry. Note however that if for whatever reason a case always hangs up (e.g. due to a incompatible image) this would retry forever. With that fear in mind I did not enable this. I can make it configurable in the next version!


    Marcel

    I am on Windows, so I guess I will have to wait until the next version. It would be WONDERFUL to be able to configure that. If I manually resend the study, it will go through after 1 - 3 tries. I think it is the remote PACS having an issue, but it is a 3rd party organization that I have no control over.

    Hi,


    you can try to use an exportconverter like this, which does retry at image level:


    RetryForwardFailed = 1
    ForwardAssociationLevel = SERIES
    ExportConverter0 = forward to AE channel *


    This will retry (on image level due to the first setting), but the disadvantage is that is blocking and may hold up reception of images. Though a channel * clause will give different incoming associations different outgoing associations (up to 20) so it may not be so bad.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login