*** multiplex: connection terminated

  • Hi,


    I use Conquest 1.4.14. Have two instances on one machine (different ports). Have 16 export converters on the first instance.


    Get message on the second instance *** multiplex: connection terminated


    Get messages on the first instance like *** ExportConverter8.0: Forward failed to connect to host BLUMRATHCQUEST
    which is blocking the server


    Have already set WorkListReturnsISO_IR_100 = 0
    but seems not to help


    Another solution ??


    Thank you
    Helmut

  • Hi,


    yes, I am forwarding from the first to the second instance.
    Query and Move works fine (from the 1st to the 2ns and vice versa).
    The 2nd instance has the same configuration as the 1st, except the changed Port-number.


    Helmut

  • Hi Marcel,


    the exact code is below. Please realize, that I cancelled out some lines, and so far there is no more failure yet.


    # Configuration of forwarding and/or converter programs to export DICOM slices
    #ForwardAssociationLevel = IMAGE
    #ForwardAssociationCloseDelay = 5
    #ForwardAssociationRefreshDelay = 3600
    #ForwardAssociationRelease = 1


    ExportConverters = 16
    ExportFilter0 = ReferPhysi like 'Dr. Leitner'
    ExportConverter0 = forward compressed as n4 to LEITNERCQUEST
    ExportFilter1 = ReferPhysi like 'Dr. Ksoll'
    ExportConverter1 = forward compressed as n4 to LEITNERCQUEST
    ExportFilter2 = ReferPhysi like 'Dr. Weinert'
    ExportConverter2 = forward compressed as n4 to LEITNERCQUEST
    ExportFilter3 = ReferPhysi like 'Dr. Schlegel'
    ExportConverter3 = forward compressed as n4 to LEITNERCQUEST
    ExportFilter4 = ReferPhysi like 'Dr. Blumrath'
    ExportConverter4 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter5 = ReferPhysi like 'Dr. Lorenz'
    ExportConverter5 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter6 = ReferPhysi like 'Dr. Schlögl'
    ExportConverter6 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter7 = ReferPhysi like 'Dr. Kölling'
    ExportConverter7 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter8 = ReferPhysi like 'Dr. Winter'
    ExportConverter8 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter9 = ReferPhysi like 'Dr. Bergmann'
    ExportConverter9 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter10 = ReferPhysi like 'Dr. Himmer'
    ExportConverter10 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter11 = ReferPhysi like 'Dr. Demhartner'
    ExportConverter11 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter12 = ReferPhysi like 'Dr. Mengel'
    ExportConverter12 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter13 = ReferPhysi like 'Dr. Schmid'
    ExportConverter13 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter14 = ReferPhysi like 'Dr. Gasche'
    ExportConverter14 = forward compressed as n4 to BLUMRATHCQUEST
    ExportFilter15 = ReferPhysi like 'Dr. Sasse'
    ExportConverter15 = forward compressed as n4 to BLUMRATHCQUEST


    #ForwardCollectDelay = 600
    #MaximumExportRetries = 0
    #MaximumDelayedFetchForwardRetries = 0



    Thank you
    Helmut

  • Hi Marcel,


    bad news: the same error messages!


    So I reduced the export converters from 16 to 3. Now it seems to work properly.


    Since we use several other machines with different Conquest Servers and a lot of export converters, maybe the maximum number of export converters in the whole network ist limited?



    Helmut

  • Hello All,


    I've just came across the same problem with *** multiplex: connection terminated


    I have a Conquest running 1.4.14 receiving images from CT, MR, CR & US. All studies are immediately forwarded to a workstation with no filtering. I do not know the AETitles of the devices so Conquest is set to be promiscuous. Images from all the modalities receive and forward fine with the exception of the Toshiba Ultrasound unit. I have only one ExportConverter on this machine.


    I since learned the AETitle, IP and Port of the Toshiba Ultrasound and have entered that as a DICOM Peer in Conquest. I should know within the next 24 hours if this has made any difference. The odd thing is there is no information in the serverstatus.log file of any association request from the Toshiba Ultrasound. There is only the "*** multiplex: connection terminated" error and it takes a minute or two for it to appear.


    This is puzzling...

  • The *** multiplex: connection terminated error persists at this location. The only unique thing I can think of is that all the modalities, including Conquest, have AETitles where the first 7 characters are the same. But this doesn't affect MR & CT, only US.


    Ultrasound images generated from this ultrasound machine that were migrated from the previous archive to Conquest traveled fine. I'm only having a problem with images coming directly from the US to Conquest.

  • Hi,


    there might just be a timout due to heavy loading of the US machine: this is the only machine affected. The default is set to 300 s. You can try doubling this time. The error is intermittent, isn't it?


    TCPIPTimeOut = 300


    Marcel

  • This may not be a time-out issue. With a time-out extended to 2400 I still have the problem. Strange that I don''t see an association request from the ultrasound. I can successfully DICOM Echo ultrasound. I may try having them send images to another server application to see if the problems persist or go away.


    I've never seen this error before.

  • Well, this problem just popped up for me, conquest talking to a mobile GE MRI. The system worked one week and failed with the multiplex error the next week. The mobile unit staff denies any changes to their setup. This install of conquest is actually minimal, only one export filter. Debug log really has nothing in it of use. Sigh. I'll write back if I get any ideas.

  • I cloned the identity of Conquest using Etiam WinSCP and attempted a send from the Toshiba Aplio Ultrasound. It failed with no activity in the WinSCP log. I took this as a good sign thinking it could be a network issue. I then cloned the identity of the ultrasound unit with a laptop and successfully sent a study to Conquest. So the network is apparently OK. The situation is the Toshiba Aplio US could successfully communicate with the previous Agfa IMPAX but cannot do so with Conquest. Does the Toshiba Aplio use some proprietary non-DICOM method of communication that only Agfa can understand? Or has this ultrasound unit suddenly broken (which would be quite a coincidence). Other devices here communicate with Conquest just fine. It's a mystery right now.

  • Well, my ***multiplex: connection terminated error went away "on it's own". IT staff at the clinic denies making changes, the mobile MR guys deny making changes but the problem went away. I suppose that in my case it was some hardware issue that IT created but didn't want to admit to or dismissed as trivial. Or perhaps a Windows patch, the machine is XP SP2 set to download MS updates automatically...
    Whatever the case, I'm glad it's gone, I wish I knew what the heck happened though.


  • yeah, about this ultrasound, i heard some, some saying sometimes its being complicated matters :idea:





    _________________
    Ultrasound Repair

  • I recently had this happen for no apparent reason. I am running two instances of conquest on the same machine. I think the problem was I had edited the dicom.ini file of one instance while the server was running and left a semicolon on the end of an export converter. Once I removed the semicolon, the error message went away. Can anyone confirm that conquest is picky about the syntax of the dicom.ini?

  • Marcel,
    You are correct that it only affected the one line and not the entire file. For example:


    ExportConverter0 = forwward to machine1; forward to machine2; -- this did not forward to machine2
    ExportConverter0 = forwward to machine1; forward to machine2 -- this worked

Participate now!

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