Excellent !
Best regards.
Excellent !
Best regards.
Hi Marcel,
#b counts the number of series in the dicomquery() result, which in the above example is apparently 1.
What I want is the count of images/instances within the series...
Best regards.
Hi Marcel,
How can I get the number of images in a series with a Lua script, such as the following example ?
----------
a=DicomObject:new()
a.QueryRetrieveLevel='SERIES'
a.SeriesInstanceUID = '1.2.34534.4564564668.467897544574.3345345345'
b=dicomquery('STORESCP', 'SERIES', a)
print(b.NumberOfInstances)
----------
(NumberOfInstances is fake just for the example..)
Best regards.
Hi Marcel,
Of course... please find it attached... it is executed as a Windows Scheduled Task (dgate --dolua:... command) every 60 mins.
Best regards.
Hi Marcel,
I haven't see any retry... perhaps the error is not caught by the retry mechanism....
However, I found a workaround... I wrote a LUA script which checks every hour for missing series and instructs the sender to move them to the receiver... This seems to work fine.
Best regards,
Dimitris.
Hi Marcel,
Bit difficult to run the ping as firewalls block it and I am not sure that I can disable it.
However, if a forward fails then the sending CQ server shouldn't retry it as per the export retry settings ?
If i am not wrong, I have configure 30 retries for every failed export... however this seems not to work as expected ... or the configuration is not correct.
Best regards,
Dimitris.
Hello Marcel,
I have a setup with two CQ servers (1.4.19b and 1.4.19c respectively) where the 1st one, via an export converter, forwards series to the 2nd one (I have attached both config files and log snapshots)
The problem we face is that, randomly and rarely (let's say in 1 or 2 cases per day) the forward fails and the Sender logs the message "***preretrieve/forward xxx to: remote DICOM error" while the Receiver logs "connection terminated..."
FYI, the Sender runs on an "on premise" DELL T320 server running WinSrv2012 while the Receiver runs on a an Microsoft Azure VM running WinSrv2012 too.
Any idea of what causes the problem ?
Best regards,
Dimitris.
Hi Marcel,
Having passed a week or so, I may say that the patch version works quite stable without problems...
Thank you !
Hi Marcel,
Done... heap login switched off.
Let's see...
Best regards.
Hi Marcel,
Unfortunately the problem remains in a different form...
It does not exhaust virtual memory, however dgate32 peaks CPU utilization (50%) and RAM (50%) and does not respond in Q/R queries....eg you ask for today studies and get 0 as a response which is not the case
If you see the attached log there are still "bad heap nodes"...
Any suggestions what to do ? Should I switch back to 64 mode with daily restarts ?
Best regards.270321_log.zip
Hi Marcel,
So far so good with the patch !
I will post the logs mid next week, in case you need to check any details...
Best regards.
Hi Marcel,
The system runs now on 32bit mode...
Let's wait for the results...
Many thanks.
Hi Marcel,
I will apply the fix during noon off-peak hours and come back...
Best.
Hi Marcel,
I put the new dgate64 but it fails with message "error loading lua.dll" and the service stops
Please note that I am using ver 1.5.0
Best regards.
Of course ! Welcome !
Many thanks.
Display MoreMaybe conquest leaks when EFILM does not accept the image?
This happens 267 times in 60 moves, the big object count increases by about 330.
Can you check the logs for me to see if this is a consistent relationship between messages and jump in large objects?
Marcel
Hi Marcel,
You are absolutely right !
I checked today log and the leak occurs each time EFILM rejects an image ... so most likely this is indeed a consistent relationship.
Could you please advise how to handle this ? I am afraid that stop using EFILM, even temporarily, could not be an acceptable option...
Best regards.
Hi Marcel,
The setup is the same in all servers as it is the same VM imported (OVF files).
I used ODBC as I was familiar with MSSQL setup which is also ODBC.
I will try to check the activity on the peaks and let you know...
Worth to mention that there is a user who fetches 10-20 studies (MRI,CT) on EFILM which first get uncompressed... could this generate the leakage ?
By the way, can you please elaborate on of the heapinfo() message meaning ? what is small med and large and the respective numbers?
Best.
Hello Marcel,
Yesterday afternoon at 18:01 we had the last crash..
Specifically, at 17:00 Windows Event Viewer started to log Virtual Memory shortage events ... at 18:01 Postgres crashed with error "Out of memory" and auto restarted with auto recovery... finally the system became unusable this morning at 8:00 am and we had to restart the whole server (VM) ...
During the incident evolution, the user operations (c-Moves, C-stores, C-Finds) were usual and not extraordinary...
I have attached the Conquest log for that period as well as Postgres log, hoping that this may help to locate the problem.
FYI... in our setup Conquest connects to Postgres via ODBC and not native ... Could this be the cause of the problem ?
logs_20210322.zippostgresql-2021-03-22_000000.zip
Best regards
Hi Marcel
I added the print(heapinfo()) as you suggested and while I was doing some C-MOVEs the following events were posted to pacstrouble.log
----------------------------------------
20210320 11:45:44 7844 small (466311); 95 medium (61521) 9 large (539998) *** ERROR - bad heap node
20210320 12:00:56 34972 small (1516944); 210 medium (134631) 73 large (8084432) *** ERROR - bad heap node
-----------------------
Can you please explain what that errors mean and suggest handling ?
Best.
Hi Marcel,
I check the logs and did not notice any remarkable C-Store or C-Move activity during the jump up...
Also I checked the hardware via DELLs IDRAC dashboard and found the host system healthy...
Next step is to perform the necessary updates on Windows Server 2019 (which updates Defender as well) and see if any progress occurs...
Final step is to switch off Defender and replace it with another Antivirus...
What do you think ?
Best.