Help interpreting Cloverleaf log

This topic has 9 replies, 6 voices, and was last updated 9 years, 3 months ago by Steve Pringle.

Creator

Topic
July 23, 2015 at 1:19 am #54766
Daniel Lee
Participant
I have a lab results, radiology results, and documents interface connected over a VPN to a Physician Office EMR called gMed. They use Mirth on their side and the gMed guy doesn’t seem to really know what he’s doing. The interfaces keep cycling every 65 seconds. The Cloverleaf log is attached. From reading the log I’m thinking that their listening interface is sending junk hex characters and choking the Cloverleaf thread causing it to cycle. I’m basing this off the following line in the logs.

Code: [pti :even:DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Processing SOCKET (PDL server) event 0x0345F1F8 [pti :even:DBUG/1:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Calling cb 0x438460 [pdl :read:DBUG/2:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Events: E 32, R 8, W 0 [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] read nothing (link closed) [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] input buffer accepted 0 bytes, now 0 [pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] read returned error 0 (No error) [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Unrecoverable read error: 59090032, 6E02ents: E 32, R 8, W 0 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] IDLE and 0 bytes and an error: starting READ [pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL changed states: old 0, new 1 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Calling Tcl procedure: hci_pd.read [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] with args: {} [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Tcl procedure hci_pd.read returns ‘RECEIVE’ [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] trying to match phrase: basic-msg [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] input-error in dfa ‘basic-msg’ [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] multi_phrase_2: status = error [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Calling Tcl procedure: read.error [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] with args: {{status error} {type input-error}} [pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL signaled exception: code 1, msg device error (remote side probably shut down) [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] pdiIgnoreInput: chop to 4294967295, bolen 0 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] pdiIgnoreInput: after clear: 0 + 0 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Tcl procedure read.error returns ‘0’ [pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL changed states: old 1, new 0 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] READ operation completed (0 bytes buffered still, 0 before) [pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL changed states: old 0, new 5 [pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL changed states: old 5, new 6 [pdl :PDL :DBUG/1:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Clearing PDL listen event [pti :even:DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] tiUnregistering SOCKET (PDL server) event 0x0345F1F8 for tid 2 [pti :even:DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] evUnregister SOCKET (PDL server) event 0x0345F1F8 for tid 2 [pti :even:DBUG/1:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Closed WSAEvent 1644 on socket 1600 [msg :Msg :DBUG/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] msgFree 0x04785DEC refCnt 1 [pdl :clse:DBUG/1:to_gMed_oru_ris_p2:07/21/2015 13:21:30] PDL did shutdown: code = 1000

From the log it seems like they are sending a 6E02 (which they are denying).

Question 1) Do you agree with my assessment?

Question 2) What does the “ents: E 32, R 8, W 0” mean?
Creator

Topic

Viewing 8 reply threads

Author

Replies
- July 23, 2015 at 3:18 am #82881
  Charlie Bursell
  Participant
  You are probably correct in your assumption. Look at this:
  
  trying to match phrase: basic-msg
  
  input-error in dfa ‘basic-msg’
  
  multi_phrase_2: status = error
  
  Calling Tcl procedure: read.error
  
  This says it cannot match defined phrase
  
  Why not turn up the EO so you can see the messages and know what they are sending?
- July 23, 2015 at 1:05 pm #82882
  Daniel Lee
  Participant
  Charlie, thanks for your reply. The logs attached to this post is with the EO logging turned all the way up. All I see is those two characters being sent in. The odd part is this is an outbound thread.
- July 23, 2015 at 1:59 pm #82883
  Ed Mastascusa
  Participant
  since it sounds pretty repeatable you can always run hcitcptest and send a saved message. hcitcptest displays everything received in hex.
  
  $ hcitcptest -t mlp -h qted -p 5309
  
  Data recieved from the host will be printed to standard
  
  output in a hex dump format. (Including any encoding chars,
  
  data is dumped exactly as read.)
  
  If you wish to *send* data, just type it in and press return
  
  If you wish to *send* a file use rd_filefilename and press return
  
  Type C to quit
  
  0x00000000 (00000) 6a656e6e 79204920 676f7420 796f7572 jenny.I.got.your
  
  0x00000010 (00016) 206e756d 6265720a 00000000 00000000 .number.
  
  Client closed connection
- July 23, 2015 at 2:17 pm #82884
  Terry Kellum
  Participant
  Looks like you have PDL turned on but you need tcp and tcp trace.
  
  Here’s what I get when I turn those on.
  
  Code: [cmd :cmd :INFO/0:scc_interface_xlate:07/23/2015 10:05:03] Doing ‘xrel_post’ command with args ” [pdl :read:DBUG/2:adtord_from_uh:07/23/2015 10:05:03] Events: E 0, R 8, W 0 [pdl :PDL :DBUG/1:adtord_from_uh:07/23/2015 10:05:03] Clearing PDL listen event [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] accepted fd = 34 [pdl :PDL :DBUG/1:adtord_from_uh:07/23/2015 10:05:03] Creating PDL listen event on fd 34 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Calling Tcl procedure: hci_pd.default.open-ok [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] with args: {{client “0.0.0.0”} {status ok}} [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Tcl procedure hci_pd.default.open-ok returns ” [pdl :PDL :DBUG/2:adtord_from_uh:07/23/2015 10:05:03] PDL changed states: old 4, new 0 [pdl :init:DBUG/1:adtord_from_uh:07/23/2015 10:05:03] PDL did initialize: code = 0 [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Receiving a command [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Command client went away. Closing connection. [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Receiving a command [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Received command: ‘scc_interface_xlate xrel_post’ [cmd :cmd :INFO/0:scc_interface_xlate:07/23/2015 10:05:03] Doing ‘xrel_post’ command with args ” [pdl :read:DBUG/2:adtord_from_uh:07/23/2015 10:05:03] Events: E 0, R 8, W 0 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] read 293 bytes [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] input buffer accepted 293 bytes, now 293 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 0b 4d 53 48 7c 5e 7e 5c |.MSH|^~| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 26 7c 53 4f 41 52 49 41 |&|SOARIA| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 4e 7c 7c 49 42 45 58 7c |N||IBEX|| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 32 30 31 35 30 37 32 ||2015072| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 33 31 30 30 34 34 35 7c |3100445|| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 4f 52 47 5e 4f 32 30 ||ORG^O20| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 31 32 35 39 30 34 36 ||1259046| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 32 39 7c 50 7c 32 2e 33 |29|P|2.3| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 2e 31 7c 7c 32 30 31 35 |.1||2015| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 30 37 32 33 30 30 31 43 |0723001C| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 44 36 30 30 30 30 30 0d |D600000.| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 4d 53 41 7c 41 41 7c 7c |MSA|AA||| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 7c 30 0d 50 49 44 ||||0.PID| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 7c 32 39 36 33 35 ||||29635| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 39 35 30 5e 5e 5e 55 48 |950^^^UH| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 5e 41 4e 7c 7c 00 00 00 |^AN||xxx| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 00 00 00 00 00 00 5e 00 |xxxxxx^x| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 00 00 00 00 0d 4f 52 43 |xxxx.ORC| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 4e 41 7c 33 37 33 32 ||NA|3732| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 35 39 38 38 5e 4f 72 64 |5988^Ord| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 65 72 49 44 7e 33 37 33 |erID~373| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 32 35 39 38 38 5e 4f 63 |25988^Oc| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 63 4f 72 64 65 72 5f 49 |cOrder_I| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 44 7e 32 30 30 39 37 38 |D~200978| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 39 38 5e 4f 72 64 65 72 |98^Order| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 5f 49 44 7c 32 30 31 35 |_ID|2015| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 30 37 32 33 30 39 35 30 |07230950| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 30 37 31 30 31 32 5e 53 |071012^S| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 65 72 76 69 63 65 50 72 |ervicePr| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 6f 76 69 64 65 72 4f 72 |oviderOr| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 64 65 72 49 44 7c 7c 7c |derID|||| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 7c 7c 7c 7c 30 32 |||||||02| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 32 34 30 30 0d 4f 42 52 |2400.OBR| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 7c 7c 43 56 54 31 |||||CVT1| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 33 30 30 30 36 32 7c 7c |300062||| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 7c 7c 7c 7c 7c 7c |||||||||| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 7c 0d 1c 0d |||…| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] IDLE and 293 bytes but no error: starting READ [pdl :PDL :DBUG/2:adtord_from_uh:07/23/2015 10:05:03] PDL changed states: old 0, new 1 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Calling Tcl procedure: hci_pd.read [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] with args: {} [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Tcl procedure hci_pd.read returns ‘RECEIVE’ [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] trying to match phrase: basic-msg [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] multi_phrase_2: status = ok [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Calling Tcl procedure: read.done [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] with args: {{status ok} {end {293 0}} {data {1 290}}} [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Tcl procedure read.done returns ” [pdl :PDL :DBUG/2:adtord_from_uh:07/23/2015 10:05:03] PDL changed states: old 1, new 0 [pdl :read:DBUG/1:adtord_from_uh:07/23/2015 10:05:03] PDL did read msg: code = 0 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] READ operation completed (0 bytes buffered still, 293 before) [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Receiving a command [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Received command: ‘scc_interface_xlate xrel_post’ [cmd :cmd :INFO/0:scc_interface_xlate:07/23/2015 10:05:03] Doing ‘xrel_post’ command with args ” [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Receiving a command [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Command client went away. Closing connection. [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Receiving a command [cmd :cmd :INFO/0:scc_interface_cmd:07/23/2015 10:05:03] Command client went away. Closing connection. [pdl :wrte:INFO/1:adtord_from_uh:07/23/2015 10:05:03] [0.0.260774400] Write msg to connection [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] bound message 0xb1c28328 to `message0′ [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] (message length is 79) [pdl :PDL :DBUG/2:adtord_from_uh:07/23/2015 10:05:03] PDL changed states: old 2, new 0 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Calling Tcl procedure: hci_pd.write [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] with args: {{message message0}} [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Tcl procedure hci_pd.write returns ‘TRANSMIT’ [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] writing out 82 bytes: [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 0b 4d 53 48 7c 5e 7e 5c |.MSH|^~| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 26 7c 49 42 45 58 7c 7c |&|IBEX||| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 53 4f 41 52 49 41 4e 7c |SOARIAN|| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 7c 32 30 31 35 30 37 32 ||2015072| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 33 31 30 30 35 7c 7c 41 |31005||A| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 43 4b 7c 31 32 35 39 30 |CK|12590| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 34 36 32 39 7c 50 7c 32 |4629|P|2| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 2e 33 2e 31 7c 0d 4d 53 |.3.1|.MS| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 41 7c 41 41 7c 31 32 35 |A|AA|125| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 39 30 34 36 32 39 7c 0d |904629|.| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] 1c 0d |..| [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] write buffer has 82 bytes, currently at +0 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] wrote 82 bytes out of 82 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] write buffer has 82 bytes, currently at +82 [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Calling Tcl procedure: write.done [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] with args: {{status ok}} [pdl :PDL :DBUG/0:adtord_from_uh:07/23/2015 10:05:03] Tcl procedure write.done returns ” [pdl :PDL :DBUG/2:adtord_from_uh:07/23/2015 10:05:03] PDL changed states: old 2, new 0 [pdl :wrte:DBUG/1:adtord_from_uh:07/23/2015 10:05:03] PDL did write msg: code = 0
  
  It seems like you might need more info on the exact bytes transferred. I’ve submitted logs like these to vendors, and since it details the exact bytes sent, they usually fold as WE HAVE THE MEATS!
- July 23, 2015 at 4:34 pm #82885
  Daniel Lee
  Participant
  Terry, how do I turn tcp and tcp trace on in 6.1? I do not see that option anywhere. The thing I want to make sure everyone understands is this is an “outbound” thread. It’s set up to send data and I’m not sending anything. All I do is make a TCP/IP connection.
  
  Ed, I tried the hcitcptest and I do not see any traffic at all. Why when I connect via the hcitcptest tool wouldn’t I see any data attempt to cross but when I connect via Cloverleaf I see the following line every 65 seconds:
  Code: [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Unrecoverable read error: 59090032, 6E02ents: E 32, R 8, W 0
- July 23, 2015 at 5:16 pm #82886
  Daniel Lee
  Participant
  UPDATE: I think I’m reading too much into those .log files. I tried connecting to the hcitcptest tool instead of connecting to the gMed interface. Then I went into the hcitcptest tool and simply stopped and started the interface and I’m getting the exact same Cloverleaf log events. So, I no longer think the gMed interface is sending us junk charactes and instead think they are just cycling their interfaces after about a min. of inactivity. Look at the below Cloveleaf log events from when I just tested stopping and starting the remote interfaces.
  Code: [pti :even:DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Processing SOCKET (PDL server) event 0x03543D20 [pti :even:DBUG/1:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling cb 0x438460 [pdl :read:DBUG/2:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Events: E 32, R 8, W 0 [pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] read failed: Unknown error [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] input buffer accepted 0 bytes, now 0 [pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] read returned error 0 (No error) [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Unrecoverable read error: 60691968, 0603ents: E 32, R 8, W 0 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] IDLE and 0 bytes and an error: starting READ [pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/23/2015 13:09:13] PDL changed states: old 0, new 1 [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling Tcl procedure: hci_pd.read [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] with args: {} [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Tcl procedure hci_pd.read returns ‘RECEIVE’ [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] trying to match phrase: basic-msg [pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] input-error in dfa ‘basic-msg’ [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] multi_phrase_2: status = error [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling Tcl procedure: read.error [pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] with args: {{status error} {type input-error}} [pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] PDL signaled exception: code 1, msg device error (remote side probably shut down)
- July 23, 2015 at 8:23 pm #82887
  Jim Kosloskey
  Participant
  You indicated this is over a VPN – could be the VPN is disconnecting when there is 60 seconds of no activity.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- July 23, 2015 at 8:32 pm #82888
  Daniel Lee
  Participant
  Jim, he’s using an old version of Mirth on his side that doesn’t give him the option for a persistant connection. He had his inactivity timeout set for every 65 seconds which was the issue. I’m asking him if he can set it to every 8 hours so it will kind of act like a persistant connection. My main reason I posted this in the first place is because I misunderstood the Cloverleaf logs and thought he was sending some junk hex characters across the connection to us. Not sure why Cloverleaf logs an “Unrecoverable read error” and a “mlti_phrase_2” error when the remote side shuts down but I guess it is what it is.
- September 24, 2015 at 5:54 pm #82889
  Steve Pringle
  Participant
  If the receiving side won’t or can’t change their timeouts would a viable alternative be to use the TCP/IP Delay Connection feature in Cloverleaf (in pdl-tcpip properties protocol)?
  
  TCP/IP Delay Connection
  
  To use this feature, check Delay Connection Until Needed and Close after write on the TCP/IP Protocol Properties dialog, uncheck Auto-reconnect. The delayed connection feature overrides auto-reconnect, with one exception:
  
  If Delay Connection Until Needed and Auto-reconnect are both checked, reconnect will still be in effect, even if there is a transaction error.
  
  When selected, connection allocation is delayed until there is a message to write. By default, the check box is not selected. By using this option, the driver allocates a connection only when required for an outbound message.
Author

Replies

Viewing 8 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.