Hi,
that is a nice one. Try to stop the sserver, edit dicom.ini and then start it.
Marcel
Hi,
that is a nice one. Try to stop the sserver, edit dicom.ini and then start it.
Marcel
Hi,
The print server uses the GUI log, which is known to drop lines if the server is very busy. So, the printer option is not production grade. That one machine works and the other not maybe related to having a different number of cores?
I will see what I can do to improve upon this problem for upcoming releases.
Marcel
Hi,
OK. My question is: is each print command sent in a single association (thread in he log?). Your example would then contain two threads.
Marcel
Hi,
as documented in the manual, the actual printing interface in the conquest GUI is unfortunaly not multi-user safe. Can you show me the Server status log of your overlapping operation? Maybe I can use the thread number to separate the jobs.
Marcel
Hi,
To enable debuglogging start dgate with -v, and than pass command dgate --debuglevel:4
Marcel
Hi,
Digging a little into debugging on vista64 bits: this download will allow you to give me more info from the 64 bit version:
ftp://ftp-rt.nki.nl/outbox/Mar…er/dgate64withsymbols.zip
Is the server core (64 bits), with debug information (pdb file). If you place both in the dicomserver directory, process explorer will show you symbols for the thread stack - that makes it much easier for me to find the culprit!
And here is the same set for 32 bits:
ftp://ftp-rt.nki.nl/outbox/Mar…rver/Dgate32withdebug.zip
Stack traces with these versions would be highly appreciated.
By the way, these server cores contain debug information but are identically optimized, so performance should be identical.
Thanks,
Marcel
Hi,
both will be non-clean stops. If the server is active, the thread recieving the quit command will immediately bring down all other threads. So there is no difference. I added the --quit command for completeness.
Marcel
Hi,
conquest does not provide TLS. If you need a secure transport you can tunnel, e.g., using SSH.
Marcel
Hi,
this is normal behavior. See the sticky "why not chnage patient ID".
Marcel
Hi Steini,
these are the correct dumps. I hope to get a few more from the others as well. By the way, we have seen this problem in our hospital as well, after I asked.
Marcel
Hi,
can you find the list between the last update before december 15 and december 15.
Marcel
Hi Grisha,
I believe the error is only in logging. If the GUI cannot keep up with server, it loses lines. You can try to install as service and close the GUI. And then inspect the log files again after performing a few such transactions. If the GUI is closed, the server logs directly to file and cannot lose any lines.
Marcel
Hi,
as documented in the manual, this message always appears and does not hurt. It is in an obsolete part of the UCdavis code.
Marcel
Hi,
can you show the debug log of the correct and failed query?
Marcel
Hi,
is this all you get from conquest in debug log mode? In addition, it would be interesting to get a stack trace from the 'hanging' thread usign process explorer, see: http://www.image-systems.biz/f…topic.php?f=33&t=1809</a>
Marcel
Hi,
typically the root of an UID is set in the configuration (as in conquest). In the exportconverters you can test on a substring of any dicom tag, including the UIDs. But the UID root will be different for each machine.
Marcel
Hi,
this must be a bug. Is the CPU load going up when the thread does not end?
Marcel
Hi,
you will have to write a shell script. The shell runs dgate -ffNNNN where NNNN is nightlycleanthreshhold.
Marcel
Hi,
Drag and drop is to the server GUI - not for linux. The web interface works from anywhere for windows and linux, does not have to be IE. But for serious use, you will have to write some program or batch file or shell script (running on the same computer / directory as conquest) that takes HL7 files and loads them with dgate --loadhl7:file. Did you scan the manual ?
Marcel
Ah, good.
Can you show me a debug log (checkbox on, up arrow 4 times) from conquest when this problem occurs. I would like to see the messages exchanged.
Thanks,
Marcel