Rev 2 mlp_tcp.pdl

This topic has 8 replies, 2 voices, and was last updated 16 years ago by Ian Morris.

Creator

Topic
December 22, 2008 at 7:09 pm #50531
Ian Morris
Participant
Hello,

I (think) I have a problem related to the mlp_tcp.pdl ever since I installed the Rev2 patch. My messages are going into a state 101 and won’t leave my outbound thread.

The outbound thread goes to another site on the same server.

Any thoughts?

Code: [pdl :open:INFO/0:summit2_adt_send:12/22/2008 14:52:55] Loading PDL driver ‘mlp_tcp.pdl’ [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] PDL does not exist in site, and master site is not set; search in root. [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] PDL found in root. [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Loading driver: /opt/quovadx/qdx5.6/integrator/pdls/mlp_tcp.pdo [dbi :elog:DBUG/3:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] Looking for mid in error db [dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keylock’ [dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keyfind, keyval:’ [dbi :rlog:DBUG/3:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] Looking for mid in recovery db [dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (0) ‘cl_keyfindlock: About to do d_keylock’ [dbi :dbi :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] (1000) ‘cl_keyfindlock: About to do d_keyfind, keyval:’ [msg :Mid :DBUG/3:summit2_adt_send:12/22/2008 14:52:55] Assigned mid [0.0.121994] to msg 0xb76f7028 [msg :Msg :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] [0.0.121994] MSG alloc 0x0xb76f7028 [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Loaded: tcpip-mlp (version 2.0) [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Evaling: proc hci_pd.write { info } { global MsgId keylget info message MsgId keylset continuations ok write.done keylset continuations error write.error keylset continuations timeout [list 15000 write.timeout] hci_pd_send basic-msg [list [list data [list message $MsgId]]] $continuations } proc write.done {info} {} proc write.error {info} { hci_pd_report_exception 1 “write failure” hci_pd_set_result_code 1 } proc write.timeout {info} { global MsgId msgmetaset $MsgId FLAGS {{proto_timeout 1}} hci_pd_set_result_code 1 } proc hci_pd.read {info} { keylset continuations basic-msg read.done keylset continuations error read.error keylset continuations timeout [list 15000 read.timeout] hci_pd_receive $continuations } proc read.done {info} { keylset accept text [list [keylget info data]] keylset accept end [keylget info end] hci_pd_accept $accept } proc read.error {info} { keylget info type type switch -exact — $type { input-error { hci_pd_report_exception 1 “device error (remote side probably shut down)” hci_pd_ignore_input -all } no-match { hci_pd_ignore_input 1 hci_pd_ignore_input -until xb } default { hci_pd_report_exception 2 “unknown fail: $type” hci_pd_ignore_input -all } } } proc read.timeout {info} { hci_pd_ignore_input 1 hci_pd_ignore_input -until xb } [pdl :PDL :DBUG/2:summit2_adt_send:12/22/2008 14:52:55] PDL changed states: old 7, new 4 [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Calling Tcl procedure: hci_pd.initialize [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] with args: {} [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Tcl procedure hci_pd.initialize returns ” [pdl :PDL :INFO/0:summit2_adt_send:12/22/2008 14:52:55] connected to 172.17.40.78 on port 8001 [pdl :PDL :DBUG/0:summit2_adt_send:12/22/2008 14:52:55] tcp-client: attempting connect to: 172.17.40.78:8001 [pdl :PDL :INFO/0:summit2_adt_send:12/22/2008 14:52:55] tcp-client: connect error (Operation now in progress) [pdl :PDL :DBUG/1:summit2_adt_send:12/22/2008 14:52:55] PDL setting timeout in 0.10 seconds [diag:leak:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] diag ev alloc 0x0xa4909b0 [diag:leak:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] diag dqe alloc 0x0xa499058 [pti :even:DBUG/0:summit2_adt_send:12/22/2008 14:52:55] Registering TIMER () event 0x0xa4909b0 for tid 4
Creator

Topic

Viewing 7 reply threads

Author

Replies
- December 22, 2008 at 7:32 pm #66490
  Jim Kosloskey
  Participant
  Ian,
  
  I doubt the pdl (especially mlp_pdl) is causing you to have a trxid issue.
  
  Is the message erroring out your inound message or is it a reply from the receiving system?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 22, 2008 at 7:54 pm #66491
  Ian Morris
  Participant
  I’m not sure….
  
  It’s a sending thread that goes to another site. I can tell you that when this thread first receives the message it is a valid message. I was thinking it might be problem related to this:
  
  ~~Quote:~~
  
  If you use check_ack (known as validate_reply in some recover_33 packages), then make sure the logic in the proc is based on check_ack from recover_56.tcl. This updated procedure uses the OBMSGID argument in place of the ob_save global variable.
  
  4. Look for a line in your check_ack that looks like the following:
  
  set my_mh $ob_save
  
  Replace it with the following:
  
  keylget args OBMSGID my_mh
  
  I’m thinking it’s related because we use the recovery33 proc in our environment.
  
  I don’t think the recovery 33 is a problem though because we are not making use of check_ack in this situation.
- December 22, 2008 at 8:27 pm #66492
  Jim Kosloskey
  Participant
  Ian,
  
  Check the Error DB and see what message is in there.
  
  Is it your outbound message or a reply?
  
  Trxid errors are generated when there is an inbound messge (or reply) for which there is no valid routing and the message has reached the route function (in other words not disposed of after receipt).
  
  Now it is true you need to validate your acknowledgment handling carefully with 5.6 Rev2 and you should have acknowledgment handling even in a site-to-site connection.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 23, 2008 at 12:45 pm #66493
  Ian Morris
  Participant
  Jim,
  
  I would say it’s an outbound message. Here’s what the error db looks like…
  
  Code: -bash-3.1$ hcidbdump -e -m 0.0.122405 C l T a y F s p w Created Message Id s e d Prio State Length Source Dest ——– ————– – – – —- —– —— ————— ————— 16:16:24 [0.0.122405] E D N 5120 101 74 summit2_adt_sen
  
  Code: -bash-3.1$ hcidbdump -e -L -m 0.0.122405 msg: 0x0xb7da903c msgType : DATA msgClass : ENGINE msgState : Unsupported Trxid (101) msgPriority : 5120 msgRecoveryDbState: 3 msgFlags : 0x8002 msgMid : [0.0.122405] msgSrcMid : midNULL msgSrcMidGroup : midNULL msgOrigSrcThread : summit2_adt_send msgOrigDestThread : msgSrcThread : summit2_adt_send msgDestThread : msgXlateThread : msgSkipXlate : 0 msgSepChars : msgNumRetries : 0 msgGroupId : 0 msgDriverControl : msgRecordFormat : msgRoutes : msgUserData : msgStaticIsDirty : 0 msgVariableIsDirty: 0 msgTimeStartIb : 1229980584.247 msgTimeStartOb : 1229980119.690 msgTimeCurQueStart: 0.000 msgTimeTotalQue : 0.229 msgTimeRecovery : 1229980584.539 msgEoConfig : 0x(nil) msgData (BO) : 0x0xb7da9120 message : ‘MSH|^~&|ADM||||200812220707||ADT^A03|136552|D|2.2|||AL|NEx0dMSA|AA|136552|x0d’
  
  Here’s the original message…
  
  Code: MSH|^~&|ADM||||200812220707||ADT^A03|136552|D|2.2|||AL|NE EVN|A03|200812220706 PID|1|HSMTVD0002184|H001418|H1296|GRINCH^MR.^^^^||19701201|M|^^^^^|CA|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201||(171)267-3000|(717)267-3000||M|UN|H00000023325|000-00-0000|| NK1|1|GRINCH^LOU^WHO^^^|WI^01 WIFE|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000||NOK NK1|2|GRINCH^LOU^WHO^^^|WI^01 WIFE|10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000||NOT NK1|3|CHBGHOSP||112 N SEVENTH ST^^CHAMBERSBURG^PA^17201||(717)267-3000|EMP||||||CHAMBERSBURG HOSP|||||||||||||||||||||FT PV1|1|I|CPCUS^0224^2|EL|||SHELLY^Shelly D.O.^R^Lucas^^^|||PCU||||PHY|||SHELLY^Shelly D.O.^R^Lucas^^^|IN||SP||||||||||||||||SNF|||CHBG||DIS|||200811190849|200812220703|||||||MARTZL^Martzluf^Douglas^R^^^M.D.| PV2||PCU^PROGRESSIVE CARE UNIT|FEELING GREEN (?FOOD POISONING) OBX|1|CE|ZADCOUNTY2^Enter county of patient:^ADM||FRANKLIN^Franklin County||||||F OBX|2|CE|ZADDSPRO23^Discharged To Skilled Nur Home:^ADM||395012^Menno Haven||||||F OBX|3|TX|ZADDSPRON^Needed To Go With Nurse:^ADM||N||||||F OBX|4|TX|ZADDSPROTX^Was Transfer Summary Printed (DC to Rehab)?^ADM||Y||||||F OBX|5|TX|ZADECF^Is Patient a transfer from an Extended Care Facility?^ADM||N||||||F OBX|6|TX|ZADESBL^Have you ever had ESBL?^ADM||N||||||F OBX|7|TX|ZADHIPAA1^1. Do you want your information in our Facility Directory?^ADM||N||||||F OBX|8|TX|ZADHIPAA2^3. Do you want your Religious Affiliation shared?^ADM||N||||||F OBX|9|TX|ZADHIPAA3^4. Do you want us to notify your church of your admission?^ADM||N||||||F OBX|10|TX|ZADHIPAA6^**Was this info verified by Hipaa Questionnaire?^ADM||Y||||||F OBX|11|TX|ZADHISPAN2^Is Patient of Hispanic or Latino Origin?^ADM||N||||||F OBX|12|TX|ZADHOSPITA^Is this a Hospitalist Patient?^ADM||N||||||F OBX|13|TX|ZADINTRP^Interpreter Needed?^ADM||N||||||F OBX|14|TX|ZADMCRNOT5^Date^ADM||||||||F OBX|15|TX|ZADMCRNOT7^Y/N^ADM||||||||F OBX|16|TX|ZADMCRNOT8^Date^ADM||||||||F OBX|17|TX|ZADMCRNOT9^Comment^ADM||||||||F OBX|18|TX|ZADMRSA^Have you ever had the infectious bacteria MRSA?^ADM||N||||||F OBX|19|TX|ZADPRIV1^Date Privacy Notice Was Given:^ADM||20081119||||||F OBX|20|TX|ZADPRIV2^Was Privacy Acknowledgement Form Refused?^ADM||N||||||F OBX|21|TX|ZADPRIV3^Reason Patient or Representative Refused to Sign:^ADM||||||||F OBX|22|TX|ZADVRE^Have you ever had the infectious bacteria, VRE?^ADM||N||||||F OBX|23|TX|ZADVRSA^Have you ever had the infectious disease, VRSA?^ADM||N||||||F OBX|24|CE|ZCODE^*Code Status:^ADM||I^I:FULL CODE||||||F OBX|25|TX|ZADMAELIG2^Verified eligibility on EVS (Y/N):^INS^^^SP||Y||||||F OBX|26|TX|ZADMAELIG3^Date Verified:^INS^^^SP||20081119||||||F GT1|1||GRINCH^MR.||10 WHOVILLE AVENUE^^CHAMBERSBURG^PA^17201|(171)267-3000|||||SP|000-00-0000||||CHBGHOSP|112 N SEVENTH ST^^CHAMBERSBURG^PA^17201|(717)267-3000||FT| IN1|1|SP||SELF PAY INSURANCE|||||||CHBGHOSP|||||GRINCH^MR.^^^^|SP||||||||||||20081119|PCHILCOTE||||||||||||FT^1 FULL-TIME EMPLOYED|||QUEUED UB2|||||||
- December 23, 2008 at 1:57 pm #66494
  Jim Kosloskey
  Participant
  ian,
  
  Nope – that is an acknowledgment.
  
  Check to make sure you are killing the reply in your acknowledgment handling on the outbound thread.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 23, 2008 at 2:59 pm #66495
  Ian Morris
  Participant
  I talked to David from tech support and he had the same suggestion you did. He also suggested checking the Outbound only option. Here’s what my thread looks like now…
  
  Thank you for your help!
- December 23, 2008 at 3:04 pm #66496
  Jim Kosloskey
  Participant
  Ian,
  
  Did that take care of your issue?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 23, 2008 at 4:48 pm #66497
  Ian Morris
  Participant
  Yes it did. Thank you!
Author

Replies

Viewing 7 reply threads

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