Hi,
When I'm trying to pull large studies(12GB or more) from conquest to another PACS, it's throwing the socket time out error. Can you please let me know, what might be causing the issue?
It works fine with smaller studies.
Thanks,
Rohan
Hi,
When I'm trying to pull large studies(12GB or more) from conquest to another PACS, it's throwing the socket time out error. Can you please let me know, what might be causing the issue?
It works fine with smaller studies.
Thanks,
Rohan
Hi,
The timout is 300 seconds. Can you see when it occurs? Which version do you use?
Marcel
It happens whenever we are sending multiple studies and one or more among the studies are large in size.
Can we modify the default time out seconds?
I'm using version: 1.4.19b
This is the error description, we are getting:
2019-02-11 11:47:06 EST ERROR-|DicomServiceTemplate:248| Exception while read operation: Read timed out
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)[:1.8.0_65]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)[:1.8.0_65]
at java.net.SocketInputStream.read(SocketInputStream.java:170)[:1.8.0_65]
at java.net.SocketInputStream.read(SocketInputStream.java:141)[:1.8.0_65]
at com.archimed.dicom.network.PduBuffer.readFully(PduBuffer.java:94)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.PduBuffer.read(PduBuffer.java:71)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.PduReader.read(PduReader.java:25)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.AssociationIO.read(AssociationIO.java:87)[109:dicom-services-dicom-runtime-assembly:18.1.0]
........
........
.......
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)[:1.8.0_65]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)[:1.8.0_65]
at java.net.SocketInputStream.read(SocketInputStream.java:170)[:1.8.0_65]
at java.net.SocketInputStream.read(SocketInputStream.java:141)[:1.8.0_65]
at com.archimed.dicom.network.PduBuffer.readFully(PduBuffer.java:94)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.PduBuffer.read(PduBuffer.java:71)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.PduReader.read(PduReader.java:25)[109:dicom-services-dicom-runtime-assembly:18.1.0]
at com.archimed.dicom.network.AssociationIO.read(AssociationIO.java:87)[109:dicom-services-dicom-runtime-assembly:18.1.0]
....
Hi,
can you show the conquest side, which has timestamps. And yes you can change the timeout - pls have a look in teh manual.
Marcel
Hi Marcel,
Following is the Log from Conquest:
[CONQUEST7119C] Monitoring for files in: d:\dicomserver\dicomserver1419d1\data\incoming
[CONQUEST7119C] DGATE (1.5.0-alpha-test1, build Mon Mar 18 11:19:20 2019, bits 64) is running as threaded server
[CONQUEST7119C] Database type: built-in SQLite driver
[CONQUEST7119C] User interface test: local server is running!
[CONQUEST7119C]
[CONQUEST7119C] UPACS THREAD 1: STARTED AT: Tue May 14 11:48:21 2019
[CONQUEST7119C] Calling Application Title : "EDGE"
[CONQUEST7119C] Called Application Title : "CONQUEST7119C "
[CONQUEST7119C] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 64234
[CONQUEST7119C] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
[CONQUEST7119C] (StudyRootQuery) search level: STUDY
[CONQUEST7119C] C-Find (StudyRoot) located 1 records
[CONQUEST7119C] UPACS THREAD 1: ENDED AT: Tue May 14 11:48:22 2019
[CONQUEST7119C] UPACS THREAD 1: TOTAL RUNNING TIME: 1 SECONDS
[CONQUEST7119C]
[CONQUEST7119C] UPACS THREAD 12: STARTED AT: Tue May 14 11:48:55 2019
[CONQUEST7119C] Calling Application Title : "EDGE "
[CONQUEST7119C] Called Application Title : "CONQUEST7119C "
[CONQUEST7119C] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 64234
[CONQUEST7119C] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.2" 1
[CONQUEST7119C] C-Move Destination: "EDGE "
[CONQUEST7119C] Number of Images to send: 97
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000001_15566491930000.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000002_15566491990001.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000003_15566492140002.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000004_15566492170003.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000005_15566492170004.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000006_15566492170005.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000007_15566492170006.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000008_15566492170007.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000009_15566492280008.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000010_15566492340009.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000011_1556649242000a.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000012_1556649243000b.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000013_1556649244000c.dcm
[CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000014_1556649249000d.dcm
[CONQUEST7119C] ***VR:ReAlloc out of memory allocating 249521472 bytes
[CONQUEST7119C] ***A fatal error occurred (out of memory) - closing server
Ah,
that is a lot clearer. Can you run this on the command line (in the server folder) when the server is running?
dgate --checklargestmalloc:
This should printour how much memory is free. 249521472 bytes is a lot but not crazy. it should just do this.
Marcel
Hm,
there may be a memory leak. Your error according at 250MB, yet this check showns 5000MB free. Can you restart the server and look at memory consumption in task manager as it runs.
Thanks,
Marcel
Hello Mercel,
The memory peaked at 97% while transferring the files. Following is the error it generated while kept the debugging level at "1":
5/15/2019 12:28:53 PM [CONQUEST7119C] Sending file : d:\dicomserver\dicomserver1419d1\data\xxxxxxxxx\1.2.840.710410.0.785.32755.6926805104.189.7_0000_000009_15566492280008.dcm
5/15/2019 12:28:53 PM [CONQUEST7119C] Image Loaded from Read Ahead Thread, returning TRUE
5/15/2019 12:28:58 PM [CONQUEST7119C] ReadAheadThread: readahead > 0020
5/15/2019 12:29:00 PM [CONQUEST7119C] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
5/15/2019 12:29:00 PM [CONQUEST7119C] ReadAheadThread: readahead > 0021
5/15/2019 12:29:01 PM [CONQUEST7119C] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
5/15/2019 12:29:02 PM [CONQUEST7119C] ReadAheadThread: readahead > 0022
5/15/2019 12:29:03 PM [CONQUEST7119C] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
5/15/2019 12:29:18 PM [CONQUEST7119C] ReadAheadThread: readahead > 0023
5/15/2019 12:29:20 PM [CONQUEST7119C] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
5/15/2019 12:29:40 PM [CONQUEST7119C] Protocol error 0 in PDU:Read
5/15/2019 12:29:40 PM [CONQUEST7119C] Retrieve: remote connection dropped after 8 images, 89 not sent
Thanks,
Rohan
Hm,
could it be that the Java side has a 20s timeout?
5/15/2019 12:29:20 PM
5/15/2019 12:29:40 PM [CONQUEST7119C] Protocol error 0 in PDU:Read
Marcel
Hi Marcel,
Our application has 60 sec timeout.
The Protocol error time difference is inconsistent:
5/15/2019 12:48:15 PM [CONQUEST7119C] ReadAheadThread: warning - resolving deadlock due to erratic incoming order
5/15/2019 12:48:23 PM [CONQUEST7119C] Protocol error 0 in PDU:Read
Thanks,
Rohan
Hi,
what worries me also is that there are different errors. In any caes the "resolving deadlock" messgae is not an issue, that is an internal thing, But can you chnage the timout on the java side?
Marcel
Hi Marcel,
following are some snapshots of memory usage by conquest while transferring files.
It reaches almost 99% and then the error throws. Then the memory usage comes down.
Thanks,
Rohan
Thanks,
can you post your dicom.ini. Are there any other special settings?
Marcel
# This file contains configuration information for the DICOM server
# Do not edit unless you know what you are doing
[sscscp]
MicroPACS = sscscp
# Network configuration: server name and TCP/IP port#
MyACRNema = CONQUEST7119C
TCPPort = 5679
# Host, database, username and password for database
SQLHost = localhost
SQLServer = D:\dicomserver\dicomserver1419d1\Data\dbase\conquest.db3
Username =
Password =
SqLite = 1
DoubleBackSlashToDB = 0
UseEscapeStringConstants = 0
# Configure server
ImportExportDragAndDrop = 1
ZipTime = 05:
UIDPrefix = 1.2.826.0.1.3680043.2.135.737131.84593541
EnableComputedFields = 1
FileNameSyntax = 4
# Configuration of compression for incoming images and archival
DroppedFileCompression = un
IncomingCompression = un
ArchiveCompression = as
# For debug information
PACSName = CONQUEST7119C
OperatorConsole = 127.0.0.1
DebugLevel = 1
# Configuration of disk(s) to store images
MAGDeviceFullThreshHold = 30
MAGDevices = 1
MAGDevice0 = d:\dicomserver\dicomserver1419d1\data\
Ok,
nothing special. But where is the JK compression configured? And xan you see if the memory issue goes up per image, over over receiving multiple images, or for a single image. I assume it goes up when you are reading stuff from conquest.
Marcel
Hi,
You can also try to add "ReadAheadThread=0" to the main section of dicom.ini. This would limit memory use. I have never seen issues with it though, but maybe when you are loading lots of very big objects at once and compressing them.
Marcel
Hello Marcel,
It happens when we are trying to download multiple images. For example, the size of one study is 13 gb containing 97 images. I’ll try with the “read ahead thread”.
Thanks,
Rohan
Ok,
you are really running out of memory! Read ahead loads 5 images max. I would suggest to add memory.
Marcel
Hi Marcel,
We increased the memory from 4GB to 8GB. Still the read time out error is occurring. We tried with the ReadAhead thread = 0 as well, still didn't work.
I've attached the screenshots for your reference.
Here one thing I would like to mention is that, the OS(Windows memory manager) is probably killing the threads whenever CONQUEST is flooding the memory and reaching 100% usage. Can we limit the memory usage in any of the CONQUEST library files and compile the codes?
Please let us know.
Thanks,
Rohan
Don’t have an account yet? Register yourself now and be a part of our community!