Problem with export converters

  • Hello,


    On our Conquest server (1.5.0c), I try to start some processing workflows based on scans being received. I created two export converter rules for that:


    Code
    ExportConverters = 2
    ExportConverter0 = ifnotequal "%V0008,1090","Elekta XVI"; stop; ifnotequal "%V0008,0070","ELEKTA"; stop; ifnotequal "%V0020,0013", "0"; stop; process series after 15 by powershell -WindowStyle hidden -File .\RT-CBCT-DR-Creation-Trigger.ps1 "RT-CBCT-DR-Creation-Trigger-A.json" "%V0020,000e" "KNO_protocol"
    ExportConverter1 = ifnotequal "%V0008,1090","Elekta XVI"; stop; ifnotequal "%V0008,0070","ELEKTA"; stop; ifnotequal "%V0020,0013", "0"; stop; process series after 20 by powershell -WindowStyle hidden -File .\RT-CBCT-RS-Creation-Trigger.ps1 "RT-CBCT-RS-Creation-Trigger-A.json" "%V0020,000e" "KNO_protocol"

    So when a scan which matches certain criteria is encountered, a powershell script is started after a delay, and this powershell script then triggers a workflow on a server somewhere else. The trigger process takes about 5 seconds to complete.


    In this case, the criteria are the same for both export converters, and if a scan is encountered, both export converters should fire, and start different workflows on different servers.


    The problem is that only only one export converter is executed, the first one. When I restart the server and retry, both export converters are executed. When I upload the scan again some time later, only one export converter is executed. When I swap the contents of the export converters around, still only the first one executes.


    Does anybody have an idea about what I'm doing wrong? Any help much appreciated!


    Thanks and kind regards,


    Martijn

  • Hi,


    The queing mechanism thinks both process series commands are the same and queues them as one because they work on the same data (every object is queued, so it needs to remove duplicates). It only checks patientid, operation (process), studyuid, and seriesuid. It does not check the "by" clause at all which is a bug on my side. I can change the code to let is it check the latter in which case you would have to make a subtle difference in the "by" clause to make it work.


    Marcel

  • Hey marcel, long time! I'm finally getting our cluster worked up for a migration to 1.5.0c on linux of course. In my testing I'm finding that my delayedforwarderthreads seem to be working on the same object at the same time. I'm assuming this is related to the discussion above... would really love a code fix so we can use this sweet sweet parallelization if that is the case. If not-- any ideas?


    This is with

    ForwardAssociationLevel = Series (I've tried image, and study - I did have some success with study but it would initially fail to send and then the send speed it achieved was less than a single thread.)

    DelayedForwarderThreads = 2


    Code
    Fri Mar 17 18:13:46 2023 Starting 2 DelayedForwarderThreads
    Fri Mar 17 18:13:46 2023 Started 18 export queue thread(s)
    Fri Mar 17 18:13:47 2023 Queue: retrying processing of file /conquest/data/20162809/1.3.12.2.1107.5.2.50.176059.30000023011712250368900000012_0006_000003_16790975700000.dcm
    Fri Mar 17 18:13:47 2023 Exportconverter0.0 executes: sh /conquest/scripts/cqStats/cqExportNotifier.sh PACSSERVER MR CONQUESTSRV1 exporting PACSQC-CC 1.3.12.2.1107.5.2.50.176059.30000023011712250368900000016 20162809 10006833
    Fri Mar 17 18:13:47 2023 Queue: retrying processing of file /conquest/data/20162809/1.3.12.2.1107.5.2.50.176059.30000023011712250368900000012_0006_000003_16790975700000.dcm
    Fri Mar 17 18:13:47 2023 Exportconverter0.0 executes: sh /conquest/scripts/cqStats/cqExportNotifier.sh PACSSERVER MR CONQUESTSRV1 exporting PACSQC-CC 1.3.12.2.1107.5.2.50.176059.30000023011712250368900000016 20162809 10006833
    Fri Mar 17 18:13:47 2023 ExportConverter0.1: forward /conquest/data/20162809/1.3.12.2.1107.5.2.50.176059.30000023011712250368900000012_0006_000003_16790975700000.dcm to PACSSERVER
    Fri Mar 17 18:13:47 2023 ExportConverter0.1: forward /conquest/data/20162809/1.3.12.2.1107.5.2.50.176059.30000023011712250368900000012_0006_000003_16790975700000.dcm to PACSSERVER



    /edit: I'm using the precompiled binary with SQLite

Participate now!

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