Posts by jheleniak

post your export converter from your ini and is that host properly added to the known hosts acrnema.map??

reading some other posts regarding dgate conquest wado implementation, it is dead in the water until 1.4.16d when contentType=application%2Fdicom is implemented. This would then make weasis work properly. I will post the code when I can test it out on the 1.4.16d.

both work and compile (linux) just fine under 64-bit.

i wrote a php jnlp/xmls generator weasis implementation that could easily be ported to support conquest db. if you are interested i can post for everyone. it was originally for dcm4che database schema but could easily be modified to work with conquest db.

Eagerly awaiting..also thanks for adding '*' query fix for non-standard queries from GE Workstation etc.

using j2 it still happens. just adds delays but never misses images. after tcpip timeout seems to be reached it goes through on new association. there is definitely no issue with format of images/presentation contexts etc. still a mystery. added in new 1.4.16c dgate....here is pacstrouble and some servstatus debug on 4 level

pacstrouble log during multiplex
20110630 13:26:06 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:06 ***In 0 presentation contexts
20110630 13:26:06 ***#Possible transfer syntaxes: 10
20110630 13:26:06 *** multiplex: connection terminated
20110630 13:26:09 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:09 ***In 0 presentation contexts
20110630 13:26:09 ***#Possible transfer syntaxes: 10
20110630 13:26:09 *** multiplex: connection terminated
20110630 13:26:12 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:12 ***In 0 presentation contexts
20110630 13:26:12 ***#Possible transfer syntaxes: 10
20110630 13:26:12 *** multiplex: connection terminated
20110630 13:26:15 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:15 ***In 0 presentation contexts
20110630 13:26:15 ***#Possible transfer syntaxes: 10
20110630 13:26:15 *** multiplex: connection terminated
20110630 13:26:18 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:18 ***In 0 presentation contexts
20110630 13:26:18 ***#Possible transfer syntaxes: 10
20110630 13:26:18 *** multiplex: connection terminated
20110630 13:26:21 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:21 ***In 0 presentation contexts
20110630 13:26:21 ***#Possible transfer syntaxes: 10
20110630 13:26:21 *** multiplex: connection terminated
20110630 13:26:24 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:24 ***In 0 presentation contexts
20110630 13:26:24 ***#Possible transfer syntaxes: 10
20110630 13:26:24 *** multiplex: connection terminated
20110630 13:26:27 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:27 ***In 0 presentation contexts
20110630 13:26:27 ***#Possible transfer syntaxes: 10
20110630 13:26:27 *** multiplex: connection terminated
20110630 13:26:30 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:30 ***In 0 presentation contexts
20110630 13:26:30 ***#Possible transfer syntaxes: 10
20110630 13:26:30 *** multiplex: connection terminated
20110630 13:26:33 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:26:33 ***In 0 presentation contexts
20110630 13:26:33 ***#Possible transfer syntaxes: 10
20110630 13:26:33 *** multiplex: connection terminated
20110630 13:32:12 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:32:12 ***In 0 presentation contexts
20110630 13:32:12 ***#Possible transfer syntaxes: 10
20110630 13:32:12 *** multiplex: connection terminated
20110630 13:32:15 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:32:15 ***In 0 presentation contexts
20110630 13:32:15 ***#Possible transfer syntaxes: 10
20110630 13:32:15 *** multiplex: connection terminated
20110630 13:32:18 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:32:18 ***In 0 presentation contexts
20110630 13:32:18 ***#Possible transfer syntaxes: 10
20110630 13:32:18 *** multiplex: connection terminated
20110630 13:32:21 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:32:21 ***In 0 presentation contexts
20110630 13:32:21 ***#Possible transfer syntaxes: 10
20110630 13:32:21 *** multiplex: connection terminated

servstatuslog
20110630 13:32:12 Connected by address: ea6ea8c0
20110630 13:32:12 ***No valid presentation contexts/transfer syntax found in 0 candidates
20110630 13:32:12 ***In 0 presentation contexts
20110630 13:32:12 ***#Possible transfer syntaxes: 10
20110630 13:32:12 InterogateAAssociateRQ failed
20110630 13:32:12 *** multiplex: connection terminated
20110630 13:32:12 Exportconverter5.0 executes: ifmatch " 7", "*5"
20110630 13:32:12 Exportconverter5.1 not executed because of previous statement

I'm pretty convinced it's something to do with JK compression. Switching to j2 seems to be the easiest solution for now and doesn't seem to require any tweaking to eliminate errors on sending/receiving sides.

I wanted to update on this. On the receiver, when deleting the dgatesop.lst file while the service is already started has eliminated the multiplex issues and errors of failed to connect on the receiving side. This leads me to believe that it is the receiving side that muddles up the list while processing images. Is there anyway to read this file into memory once during service start and not re-read during processing that could cause issues?

its a conquest forwarder that is the sending side. i did one change at a time and by restarting the sending side after it begins does nothing. by restarting only the receiving side and not the sending i was able to send the complete study with no errors. this means something on the receiving side by being restarted as a service fixes it temporarily. The logs are kind of hard to make anything out of. when it begins receiving it does have a bunch of good

CONQUEST2] 20110517 07:10:38 UPACS THREAD 7951: STARTED AT: Tue May 17 07:10:37 2011
[CONQUEST2] 20110517 07:10:38 A-ASSOCIATE-RQ Packet Dump
[CONQUEST2] 20110517 07:10:38 Calling Application Title : "CONQUEST1 "
[CONQUEST2] 20110517 07:10:38 Called Application Title : "CONQUEST2 "
[CONQUEST2] 20110517 07:10:38 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
[CONQUEST2] 20110517 07:10:38 Number of Proposed Presentation Contexts: 2
[CONQUEST2] 20110517 07:10:38 Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1
[CONQUEST2] 20110517 07:10:38 Presentation Context 1 "1.2.840.10008.1.1" 1
[CONQUEST2] 20110517 07:10:38 Server Command := 0001
[CONQUEST2] 20110517 07:10:38 Message ID := 019d
[CONQUEST2] 20110517 07:10:38 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.2"
[CONQUEST2] 20110517 07:10:38 0000,0100 2 US CommandField 1
[CONQUEST2] 20110517 07:10:38 0000,0110 2 US MessageID 413
[CONQUEST2] 20110517 07:10:38 0000,0700 2 US Priority 0
[CONQUEST2] 20110517 07:10:38 0000,0800 2 US DataSetType 258
[CONQUEST2] 20110517 07:10:38 0000,1000 42 UI AffectedSOPInstanceU "1.2.840.113704.1.111.2492.1305559672.4783"
[CONQUEST2] 20110517 07:10:38 0002,0010 22 UI TransferSyntaxUID "1.2.840.10008.1.2.4.90"
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #0 = '1.2.840.10008.1.2'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #1 = '1.2.840.10008.1.2.1'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #2 = '1.2.840.10008.1.2.4.50'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #3 = '1.2.840.10008.1.2.4.51'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #4 = '1.2.840.10008.1.2.4.53'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #5 = '1.2.840.10008.1.2.4.55'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #6 = '1.2.840.10008.1.2.4.57'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #7 = '1.2.840.10008.1.2.4.70'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #8 = '1.2.840.10008.1.2.4.90'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #0 = '1.2.840.10008.1.2'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #1 = '1.2.840.10008.1.2.1'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #2 = '1.2.840.10008.1.2.4.50'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #3 = '1.2.840.10008.1.2.4.51'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #4 = '1.2.840.10008.1.2.4.53'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #5 = '1.2.840.10008.1.2.4.55'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #6 = '1.2.840.10008.1.2.4.57'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #7 = '1.2.840.10008.1.2.4.70'
[CONQUEST2] 20110517 07:10:38 Testing transfer: '1.2.840.10008.1.2.4.90' against list #8 = '1.2.840.10008.1.2.4.90'
[CONQUEST2] 20110517 07:10:38

however when it begins to multiplex i get these only on failing threads while other threads continue to do proper presentation testing/accepting. After 60 sec tcp/ip timeout i believe it picks up again properly to get the rest of the images. I will try deleting the dgatesop.lst once it begins choking on the receiving end and see if it allows it through even without restarting dicom server.

[CONQUEST2] 20110517 07:10:56 UPACS THREAD 7966: STARTED AT: Tue May 17 07:10:56 2011
[CONQUEST2] 20110517 07:10:56 A-ASSOCIATE-RQ Packet Dump
[CONQUEST2] 20110517 07:10:56 Calling Application Title : "CONQUEST1 "
[CONQUEST2] 20110517 07:10:56 Called Application Title : "CONQUEST2 "
[CONQUEST2] 20110517 07:10:56 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
[CONQUEST2] 20110517 07:10:56 Number of Proposed Presentation Contexts: 2
[CONQUEST2] 20110517 07:10:56 Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1
[CONQUEST2] 20110517 07:10:56 Presentation Context 1 "1.2.840.10008.1.1" 1
[CONQUEST2] 20110517 07:10:56 Server Command := 0001
[CONQUEST2] 20110517 07:10:56 Message ID := 1825
[CONQUEST2] 20110517 07:10:56 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.2"
[CONQUEST2] 20110517 07:10:56 0000,0100 2 US CommandField 1
[CONQUEST2] 20110517 07:10:56 0000,0110 2 US MessageID 6181
[CONQUEST2] 20110517 07:10:56 0000,0700 2 US Priority 0
[CONQUEST2] 20110517 07:10:56 0000,0800 2 US DataSetType 258
[CONQUEST2] 20110517 07:10:56 0000,1000 42 UI AffectedSOPInstanceU "1.2.840.113704.1.111.2492.1305559134.4222"
[CONQUEST2] 20110517 07:10:56 0002,0010 22 UI TransferSyntaxUID "1.2.840.10008.1.2.4.90"
[CONQUEST2] 20110517 07:10:57 Connected by address: 0c094b0a
[CONQUEST2] 20110517 07:10:57 No valid presentation contexts found
[CONQUEST2] 20110517 07:10:57 InterogateAAssociateRQ failed
[CONQUEST2] 20110517 07:10:57 *** multiplex: connection terminated

even if i restart 1 end or both ends. the next time i push the same study the same exact way it happens. the only way it seems to go through is by retry timeouts and the tcp/ip timeout expiring for that thread. It's very strange. It's only happening from Windows XP 32bit sending to Windows 2008 R2 64bit. I have a 32bit windows 7 pro sending to same 2008 box just fine and faster without errors. Maybe it's something in the studies itself but errors don't really say anything.

This comes and goes and maybe it's study content related. I thought it was gone. I even tried using dbaseIII to eliminate possibility of mysql related problems. I tried extending ForwardAssociationCloseDelay = 30 and changing to IMAGE association level all with no luck.

I turned debugging up all the way during the errors on receiving end. Does this make any sense? It doesn't in the end fail to forward any images after reconnecting etc. It seems to always say similar info during the multiplex error. This is log from receiving end of forwarder. When multiplex happens it then created failed to connect failed to forward errors on sending side.

[CONQUEST1] 20110516 13:53:29 Server Command := 0001
[CONQUEST1] 20110516 13:53:29 Message ID := 76b1
[CONQUEST1] 20110516 13:53:29 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.2"
[CONQUEST1] 20110516 13:53:29 0000,0100 2 US CommandField 1
[CONQUEST1] 20110516 13:53:29 0000,0110 2 US MessageID 30385
[CONQUEST1] 20110516 13:53:29 0000,0700 2 US Priority 0
[CONQUEST1] 20110516 13:53:29 0000,0800 2 US DataSetType 258
[CONQUEST1] 20110516 13:53:29 0000,1000 40 UI AffectedSOPInstanceU "1.2.840.113704.7.1.1.4504.1305559565.221"
[CONQUEST1] 20110516 13:53:29 0002,0010 22 UI TransferSyntaxUID "1.2.840.10008.1.2.4.90"
[CONQUEST1] 20110516 13:53:29 Connected by address: 0c094b0a
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #0 = '1.2.840.10008.1.2'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #1 = '1.2.840.10008.1.2.1'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #2 = '1.2.840.10008.1.2.4.50'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #3 = '1.2.840.10008.1.2.4.51'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #4 = '1.2.840.10008.1.2.4.53'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #5 = '1.2.840.10008.1.2.4.55'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #6 = '1.2.840.10008.1.2.4.57'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #7 = '1.2.840.10008.1.2.4.70'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #8 = '1.2.840.10008.1.2.4.90'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #0 = '1.2.840.10008.1.2'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #1 = '1.2.840.10008.1.2.1'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #2 = '1.2.840.10008.1.2.4.50'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #3 = '1.2.840.10008.1.2.4.51'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #4 = '1.2.840.10008.1.2.4.53'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #5 = '1.2.840.10008.1.2.4.55'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #6 = '1.2.840.10008.1.2.4.57'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #7 = '1.2.840.10008.1.2.4.70'
[CONQUEST1] 20110516 13:53:30 Testing transfer: '1.2.840.10008.1.2.4.90' against list #8 = '1.2.840.10008.1.2.4.90'
[CONQUEST1] 20110516 13:53:30 Connected by address: 0c094b0a
[CONQUEST1] 20110516 13:53:30 No valid presentation contexts found
[CONQUEST1] 20110516 13:53:30 InterogateAAssociateRQ failed
[CONQUEST1] 20110516 13:53:30 *** multiplex: connection terminated
[CONQUEST1] 20110516 13:53:30

[CONQUEST1] 20110516 13:53:14 Server Command := 0001
[CONQUEST1] 20110516 13:53:14 Message ID := 6a5b
[CONQUEST1] 20110516 13:53:14 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.2"
[CONQUEST1] 20110516 13:53:14 0000,0100 2 US CommandField 1
[CONQUEST1] 20110516 13:53:14 0000,0110 2 US MessageID 27227
[CONQUEST1] 20110516 13:53:14 0000,0700 2 US Priority 0
[CONQUEST1] 20110516 13:53:14 0000,0800 2 US DataSetType 258
[CONQUEST1] 20110516 13:53:14 0000,1000 42 UI AffectedSOPInstanceU "1.2.840.113704.1.111.2492.1305559142.4244"
[CONQUEST1] 20110516 13:53:14 0002,0010 22 UI TransferSyntaxUID "1.2.840.10008.1.2.4.90"
[CONQUEST1] 20110516 13:53:15 Query Tables: DICOMImages
[CONQUEST1] 20110516 13:53:15 Columns : ObjectFile, DeviceName
[CONQUEST1] 20110516 13:53:15 Where : SOPInstanc = '1.2.840.113704.1.111.2492.1305559159.4292' AND ImagePat = '123456'
[CONQUEST1] 20110516 13:53:15 Order : (null)
[CONQUEST1] 20110516 13:53:15 FreeStore Left 94727 on C:\
[CONQUEST1] 20110516 13:53:15 Add to Table: DICOMImages
[CONQUEST1] 20110516 13:53:15 Columns: SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName
[CONQUEST1] 20110516 13:53:15 Values: '1.2.840.113704.1.111.2492.1305559159.4292', '1.2.840.10008.5.1.4.1.1.2', '90', '20110516', '111836.556000', '20110516', '111821', '450.50', '1', 'MONOCHROME2', '512', '512', '12', 'ORIGINAL\\PRIMARY\\AXIAL\\HELIX', '123456', '1.2.840.113704.1.111.2616.1305559019.14', 1305568384, '123456\\1.2.840.113704.1.111.2616.1305559019.14_0003_000090_13055683952159.dcm', 'MAG0'
[CONQUEST1] 20110516 13:53:15 Written file: C:\CONQUEST1\Data\123456\1.2.840.113704.1.111.2616.1305559019.14_0003_000090_13055683952159.dcm
[CONQUEST1] 20110516 13:53:15 ExportConverter0.1: forward C:\CONQUEST1\Data\123456\1.2.840.113704.1.111.2616.1305559019.14_0003_000090_13055683952159.dcm to CONQUEST2
[CONQUEST1] 20110516 13:53:15 Accepted compression: jk
[CONQUEST1] 20110516 13:53:15 UPACS THREAD 6320: ENDED AT: Mon May 16 13:53:15 2011
[CONQUEST1] 20110516 13:53:15 UPACS THREAD 6320: TOTAL RUNNING TIME: 48 SECONDS
[CONQUEST1] 20110516 13:53:15 Exportconverter9.0 executes: ifmatch "90", "*9"
[CONQUEST1] 20110516 13:53:15 Exportconverter9.1 not executed because of previous statement
[CONQUEST1] 20110516 13:53:15 Exportconverter6.0 executes: ifmatch "90", "*6"
[CONQUEST1] 20110516 13:53:15 Exportconverter6.1 not executed because of previous statement
[CONQUEST1] 20110516 13:53:16 Query Tables: DICOMImages
[CONQUEST1] 20110516 13:53:16 Columns : ObjectFile, DeviceName
[CONQUEST1] 20110516 13:53:16 Where : SOPInstanc = '1.2.840.113704.1.111.2492.1305559157.4285' AND ImagePat = '123456'
[CONQUEST1] 20110516 13:53:16 Order : (null)
[CONQUEST1] 20110516 13:53:16 Connected by address: 0c094b0a
[CONQUEST1] 20110516 13:53:16 FreeStore Left 94727 on C:\
[CONQUEST1] 20110516 13:53:16 Add to Table: DICOMImages
[CONQUEST1] 20110516 13:53:16 Columns: SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, AcqDate, AcqTime, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName
[CONQUEST1] 20110516 13:53:16 Values: '1.2.840.113704.1.111.2492.1305559157.4285', '1.2.840.10008.5.1.4.1.1.2', '83', '20110516', '111835.389000', '20110516', '111821', '415.50', '1', 'MONOCHROME2', '512', '512', '12', 'ORIGINAL\\PRIMARY\\AXIAL\\HELIX', '123456', '1.2.840.113704.1.111.2616.1305559019.14', 1305568384, '123456\\1.2.840.113704.1.111.2616.1305559019.14_0003_000083_1305568396215a.dcm', 'MAG0'
[CONQUEST1] 20110516 13:53:16 No valid presentation contexts found
[CONQUEST1] 20110516 13:53:16 InterogateAAssociateRQ failed
[CONQUEST1] 20110516 13:53:16 *** multiplex: connection terminated
[CONQUEST1] 20110516 13:53:16 Written file: C:\CONQUEST1\Data\123456\1.2.840.113704.1.111.2616.1305559019.14_0003_000083_1305568396215a.dcm
[CONQUEST1] 20110516 13:53:16 ExportConverter3.1: forward C:\CONQUEST1\Data\123456\1.2.840.113704.1.111.2616.1305559019.14_0003_000083_1305568396215a.dcm to CONQUEST2
[CONQUEST1] 20110516 13:53:16 Accepted compression: jk

Problems went away hopefully forever.

If you are running Windows XP unlike 2003/2008/7 where most likely the maxuserport settings are different and do not exhibit this problem, make sure to use this registry setting because I can see many many connections to mysql when receiving/forwarding at high rates ie netstat -an and this probably caused errors.

viewtopic.php?f=33&t=786#p2450

Check your dicom.ini file for

ImportExportDragAndDrop = 0

and change to ImportExportDragAndDrop = 1

http://forum.image-systems.biz…rtExportDragAndDrop#p9566

I use a few 16 TB thecus n8800 pros with 8 drives each and they perform well over nfs iscsi or samba. I use link aggregation for 2gbits bandwidth. Rebuilding milllions of objects will probably take a little while on any hardware.

Forwardassociationrelease = 1 enabled and no errors yet after patching both source and destination conquest servers with 1.4.16b executable. Sending conquest is 32-bit windows 7 pro and receiving is windows 2008 r2 64bit dgate. Keeping fingers crossed.

I found one pitfall to my multi-thread export algorithm of exporting images. When an image for whatever reason does not have an ImageNumber it would not be exported. I had to add export line for null image number images. Forwarding by crc of image does not have this problem but seemed by luck of crc result to never be faster than by image number always 0-9 threads. I also put tcp/ip timeout back to 300 default instead of 60. not sure if that ever had any effect on errors. Hoping it was just a memory leak issue. I like the delete image export option to clean up database and file after being forwarded on. It seems to do this 10 minutes by default after being exported.

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

ExportConverters = 11
ExportConverter0 = ifmatch "%V0020,0013", "*0"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter1 = ifmatch "%V0020,0013", "*1"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter2 = ifmatch "%V0020,0013", "*2"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter3 = ifmatch "%V0020,0013", "*3"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter4 = ifmatch "%V0020,0013", "*4"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter5 = ifmatch "%V0020,0013", "*5"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter6 = ifmatch "%V0020,0013", "*6"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter7 = ifmatch "%V0020,0013", "*7"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter8 = ifmatch "%V0020,0013", "*8"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter9 = ifmatch "%V0020,0013", "*9"; forward compressed as jk to CONQUEST2; delete image;
ExportConverter10 = ifmatch "%V0020,0013", ""; forward compressed as jk to CONQUEST2; delete image;

MaximumExportRetries = 0

It sounds like it could be this. I did restart dicom server sometimes but didn't put frequency of it happening together with restarts. I will see if it stays away with this fix. With settings to 0 i still get a lot of command FFFFF errors and every few days a cannot save SQL for a few images. Thinking of trying j1 but hate to lose the extra compression ratio. I will try b update.

I found a query that was done below that seems to do the same.

4/22/2011 2:27:16 PM [CONQUEST] UPACS THREAD 235: STARTED AT: Fri Apr 22 14:27:15 2011
4/22/2011 2:27:16 PM [CONQUEST] A-ASSOCIATE-RQ Packet Dump
4/22/2011 2:27:16 PM [CONQUEST] Calling Application Title : "CALLING "
4/22/2011 2:27:16 PM [CONQUEST] Called Application Title : "CONQUEST "
4/22/2011 2:27:16 PM [CONQUEST] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672
4/22/2011 2:27:16 PM [CONQUEST] Number of Proposed Presentation Contexts: 1
4/22/2011 2:27:16 PM [CONQUEST] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
4/22/2011 2:27:16 PM [CONQUEST] Server Command := 0020
4/22/2011 2:27:16 PM [CONQUEST] Message ID := 001e
4/22/2011 2:27:16 PM [CONQUEST] (StudyRootQuery) search level: STUDY
4/22/2011 2:27:16 PM [CONQUEST] Query On Study
4/22/2011 2:27:16 PM [CONQUEST] Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.StudyInsta, DICOMStudies.StudyID
4/22/2011 2:27:16 PM [CONQUEST] Values: DICOMStudies.StudyDate >= '20110422' and DICOMStudies.StudyDate <= '20110422' and DICOMStudies.StudyTime >= '000000' and DICOMStudies.StudyTime <= '235959' and DICOMStudies.PatientNam LIKE ' D%' and DICOMStudies.PatientID LIKE ' %'
4/22/2011 2:27:16 PM [CONQUEST] Tables: DICOMStudies
4/22/2011 2:27:16 PM [CONQUEST] Sorting (DICOMStudies.PatientNam) DoSort := 1
4/22/2011 2:27:16 PM [CONQUEST] Records = 0
4/22/2011 2:27:16 PM [CONQUEST] C-Find (StudyRoot) located 0 records
4/22/2011 2:27:16 PM [CONQUEST] UPACS THREAD 235: ENDED AT: Fri Apr 22 14:27:16 2011
4/22/2011 2:27:16 PM [CONQUEST] UPACS THREAD 235: TOTAL RUNNING TIME: 1 SECONDS

I found some interesting behavior coming from a GE Workstation when it is searching using blank wildcards and conquest doesn't like it. For some reason there is a space in front of the * which turns into a % in the LIKE search. This causes no records to be found when you put a space in front of at least name field for sure but not sure of patient id field. The code in conquest seems to remove the space and correctly searches patient id with it taken out when testing with buil-in query. With built in query when you put a space and then H* (last name) to cause this to happen it doesn't find records for patient name. It's reproducible. Is this an scu issue or something the scp should handle properly?

[CONQUEST] A-ASSOCIATE-RQ Packet Dump
[CONQUEST] Calling Application Title : "calling "
[CONQUEST] Called Application Title : "called "
[CONQUEST] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672
[CONQUEST] Number of Proposed Presentation Contexts: 1
[CONQUEST] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
[CONQUEST] Server Command := 0020
[CONQUEST] Message ID := 0003
[CONQUEST] (StudyRootQuery) search level: STUDY
[CONQUEST] Query On Study
[CONQUEST] Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.StudyInsta, DICOMStudies.StudyID
[CONQUEST] Values: DICOMStudies.StudyDate >= '20110422' and DICOMStudies.StudyDate <= '20110422' and DICOMStudies.StudyTime >= '000000' and DICOMStudies.StudyTime <= '235959' and DICOMStudies.PatientNam LIKE ' %' and DICOMStudies.PatientID LIKE ' %'
[CONQUEST] Tables: DICOMStudies
[CONQUEST] Sorting (DICOMStudies.PatientNam) DoSort := 1
[CONQUEST] Records = 0
[CONQUEST] C-Find (StudyRoot) located 0 records
[CONQUEST] UPACS THREAD 188: ENDED AT: Fri Apr 22 15:37:16 2011
[CONQUEST] UPACS THREAD 188: TOTAL RUNNING TIME: 0 SECONDS
[CONQUEST]
[CONQUEST] UPACS THREAD 191: STARTED AT: Fri Apr 22 15:38:06 2011
[CONQUEST] A-ASSOCIATE-RQ Packet Dump
[CONQUEST] Calling Application Title : "calling "
[CONQUEST] Called Application Title : "called "
[CONQUEST] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672
[CONQUEST] Number of Proposed Presentation Contexts: 1
[CONQUEST] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
[CONQUEST] Server Command := 0020
[CONQUEST] Message ID := 0005
[CONQUEST] (StudyRootQuery) search level: STUDY
[CONQUEST] Query On Study
[CONQUEST] Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.StudyInsta, DICOMStudies.StudyID
[CONQUEST] Values: DICOMStudies.PatientNam LIKE ' %' and DICOMStudies.PatientID LIKE ' %'
[CONQUEST] Tables: DICOMStudies
[CONQUEST] Sorting (DICOMStudies.PatientNam) DoSort := 1
[CONQUEST] Records = 0
[CONQUEST] C-Find (StudyRoot) located 0 records
[CONQUEST] UPACS THREAD 191: ENDED AT: Fri Apr 22 15:38:06 2011
[CONQUEST] UPACS THREAD 191: TOTAL RUNNING TIME: 0 SECONDS
[CONQUEST]
[CONQUEST] UPACS THREAD 192: STARTED AT: Fri Apr 22 15:38:35 2011
[CONQUEST] A-ASSOCIATE-RQ Packet Dump
[CONQUEST] Calling Application Title : "caling "
[CONQUEST] Called Application Title : "called "
[CONQUEST] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672
[CONQUEST] Number of Proposed Presentation Contexts: 1
[CONQUEST] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
[CONQUEST] Server Command := 0020
[CONQUEST] Message ID := 0006
[CONQUEST] (StudyRootQuery) search level: STUDY
[CONQUEST] Query On Study
[CONQUEST] Issue Query on Columns: DICOMStudies.StudyDate, DICOMStudies.StudyTime, DICOMStudies.AccessionN, DICOMStudies.StudyModal, DICOMStudies.ReferPhysi, DICOMStudies.StudyDescr, DICOMStudies.PatientNam, DICOMStudies.PatientID, DICOMStudies.StudyInsta, DICOMStudies.StudyID
[CONQUEST] Values: DICOMStudies.PatientID LIKE '1234-56%'
[CONQUEST] Tables: DICOMStudies
[CONQUEST] Sorting (DICOMStudies.PatientNam) DoSort := 1
[CONQUEST] Records = 2
[CONQUEST] C-Find (StudyRoot) located 2 records
[CONQUEST] UPACS THREAD 192: ENDED AT: Fri Apr 22 15:38:35 2011
[CONQUEST] UPACS THREAD 192: TOTAL RUNNING TIME: 0 SECONDS

It's back.
on receiving end
20110422 11:11:04 *** multiplex: connection terminated
20110422 11:11:07 *** multiplex: connection terminated
20110422 11:11:13 *** multiplex: connection terminated
20110422 11:11:15 *** multiplex: connection terminated
20110422 11:11:18 *** multiplex: connection terminated
20110422 11:11:21 *** multiplex: connection terminated
20110422 11:11:24 *** multiplex: connection terminated
20110422 11:11:27 *** multiplex: connection terminated
20110422 11:11:30 *** multiplex: connection terminated
20110422 11:11:33 *** multiplex: connection terminated

on sending side...no tmp files in printer files etc.

20110422 11:10:33 *** Queue: holding processing of file C:\dicomserver1416rc6\Data\P99142\1.2.840.113704.7.1.1.5888.1303484294.1_80488_000078_1303485021040c.dcm
20110422 11:10:33 *** Queue: holding processing of file C:\dicomserver1416rc6\Data\P99142\1.2.840.113704.7.1.1.5888.1303484294.1_80488_000079_1303485021040d.dcm
20110422 11:10:33 *** Queue: holding processing of file C:\dicomserver1416rc6\Data\P99142\1.2.840.113704.7.1.1.5888.1303484294.1_80488_000080_1303485021040e.dcm
20110422 11:10:33 *** Queue: holding processing of file C:\dicomserver1416rc6\Data\P99142\1.2.840.113704.7.1.1.5888.1303484294.1_80488_000081_1303485021040f.dcm
20110422 11:10:36 *** ExportConverter8.1: Forward failed to connect to host CONQUEST2
20110422 11:10:42 *** ExportConverter8.1: Forward failed to connect to host CONQUEST2
20110422 11:10:45 *** ExportConverter8.1: Forward failed to connect to host CONQUEST2
20110422 11:10:48 *** ExportConverter8.1: Forward failed to connect to host CONQUEST2

guess im going to turn back on forwardassociationrealease = 0 and see if it stays away long term.

There's nothing left in the printer files folder...i don't know if these get cleaned nightly with interface running but they are all empty. today it has run flawless with forwardassociationrelease = 1 turned back on with jk after fixing disk slowness on receiving side. for whatever reason in my case. spreading images across 10 threads has been great and both the crc and image number method both work well. in my case it seems to distribute more equally with image number because they always end in 0-9 and usually are generated sequentially and match 10 threads where as my crc i was getting more of 1 or 2 values etc and that thread would end up with more images and have to run longer while other threads were free to send.... it's been fun trying to maximize throughput..

it's very hard to make dicom saturate any more than 5-10Mb/s on Internet where there is a little latency with all the dicom association chatting going on. 700+ slices of CT in JK (100-200KB files) usually only takes 2-4 mins now which is great. It seems like multi threading on LAN conditions also speeds forwarding but in most cases probably isn't necessary.