Exceeding 20 ExportConverters due to Retry Behavior

  • We are using CQ for many workflows and enforce sending retries when transfers fail. The behavior we see displayed is that a failed send will retry indefinitely until success and will not allow any other objects to send through the EC until it is handled as the EC expects.

    Due to this, we are separating workflows into different ECs so that they do not impact one-another when there is a transfer problem. We're getting closer and closer to the documented limit of 20 ECs. Can this be extended and/or is there a way to review the retry behavior so the ECs do not completely halt when there are transfer problems?

  • Hi,

    if you are willing to go to 1.5.0 I can make it possible to extend the number. Retry works per entire convertor hence the behaviour. If you are OK without retry you can use importconverters or a mixture.



    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

  • Definitely can't go without retries. We've given that an attempt in the past but there are too many erroneous failures to rely on that. The retry firing on the entire converter is helpful for a few reasons, we have the converters notifying an influxdb database of attempts so we can monitor through grafana. Seeing in grafana when something is trying repeatedly is one of our countermeasures to manage 'clogs.'

    Moving to 1.5.0 is something we could consider. We've not moved to 1.4.19d yet so an upgrade is somewhat due. When do you foresee 1.5.0 releasing?

  • Post by marcelvanherk ().

    This post was deleted by the author themselves: Test ().