bunch of random questions/problems

  • No, it would be obvious in the logs if you used conquest printer.


    This one shows update time and source in the caption, there are 3 sources, socket updates (lines added more and log more than 0.1s older than last print), scroll update (over 1100 lines in log), and timer updates (timer ticks and log more than 0.1s older than last print). In my system it mostly ends on a timer update.


    ConquestDICOMServerDebugUpdate.zip


    Marcel

  • Interesting.. It's quite the opposite for me.

    I'm seeing mostly socketupdates.

    While the log is idle it always stops on a socketupdate. (for example after echo it stays at socketupdate)

    Under heavy log load I sometimes see scrollupdate flickering here and there so it looks like this one is working.


    I've never seen a timer update.

  • Another 'random' question, I hope you don't mind. :)


    How does the processing queue work? I realize this is a complex question so let me narrow it down a bit to a specific case which I don't understand.


    I'm forwarding all MG studies to a specific workstation, like this:

    ExportModality0 = MG

    ExportConverter0 = forward compressed as j2 to MGWORKSTATION;


    Unfortunately this machine (MGWORKSTATION) was turned OFF for almost 2 weeks. I saw the 'export failed' and queue retries in the log and I thought everything will just queue up and will be send as soon as the workstation is be back ON.


    Then I got reports from the staff about studies ( other than MG ) not "coming through" so I began investigating and found a bunch of 'holding processing of ...' messages on studies like CT, MR etc..

    Then I turned on the MGWORSTATION as a test and now I'm seeing bunch of "Queue: retrying processing of file ... CT"


    So it looks to me like a growing backlog of MG studies was somehow able to stop the processing of other unrelated studies. I didn't expect this... so my question is - why is this happening? how to prevent it? How are autorouting failures disrupting other stuff?

  • Hi,


    Each exportconverter line has its own queue and any failure on that line will block the rest of that line. They should not block any other lines. This is true for 'forward to' and 'forward compressed as .. to'.


    However, delayed export converter statements have a single own queue that retries. This queue is used for e.g. 'forward study to'. Any failure in this queue will block other e.g. 'foward study' statements from whatever line.


    To not hold forever you can configure e.g. MaximumDelayedFetchForwardRetries and MaximumExportRetries.


    Hope this makes sense.


    Marcel

  • Marcel

    Where are these QUEUES stored? I have a system that went through the above issue due to a reading station being off. And the queue seems to have survived a stop and start of the conquest service? Is that possible? I recall that the Queues used to be stored in a bin file but that doesn't seem to be the case anymore. Can you shed light. Sorry to hijack an old thread.


    Mr Johnathan Bravo.

Participate now!

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