Clovertech

hcidmd behaves differently in UPOC vs Tcl shell

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › hcidmd behaves differently in UPOC vs Tcl shell

  • Creator
    Topic
  • November 19, 2015 at 11:05 pm #54888
    Jeff Dinsmore
    Participant

      There looks to be some sort of difference between how hcicmd works exec’d from a timed UPOC vs running directly in a hcitcl shell.

      I’m running Cloverleaf 6.1.1 on RHEL 6.7.

      Tcl patch level shows 8.5.10 running in a shell or in the UPOC.

      I’m running the following to re-queue some messages.

      Code:

      exec hcicmd -s $obSite -p epic_onbase_ob -c “museBypass_to_epic_oru_pool resend ob_post_tps data 5120 $resendFile nl”

      When run from a timed UPOC, it times out waiting for response from the process command thread:

      Quote:

      No response within timeout. Please check logs to see if command was successfully completed. Exiting.

      When the same command is run from an hcitcl shell, it succeeds immediately with the following response:

      Quote:

      Placed 1 msgs from file /tmp/deferredMuseMsg_28623_1447971709.txt into the ob_post_tps data queue

      Increasing the timeout from the default 30 seconds to 120 seconds has no effect except for adding an extra 90 seconds before it returns its timeout error.

      After the UPOC completes, CL logs this well-written diagnostic message:

      Quote:

      [cmd :cmd :INFO/0:epic_onbase_ob_cmd:11/19/2015 17:54:24] Receiving a command

      [icl :tcpi:ERR /0:epic_onbase_ob_cmd:11/19/2015 17:54:24] write failed: Broken pipe

      [cmd :cmd :INFO/0:epic_onbase_ob_cmd:11/19/2015 17:54:24] Since there are some error had occured while attempted to send an Ack back to client

      [cmd :cmd :INFO/0:epic_onbase_ob_cmd:11/19/2015 17:54:24] We try to process the command anyway but no further Ack will be send back to Client

      [cmd :cmd :INFO/0:epic_onbase_ob_cmd:11/19/2015 17:54:24] Received command: ‘museBypass_to_epic_oru_pool resend ob_post_tps data 5120 /tmp/deferredMuseMsg_29422_1447973610.txt nl’

      [cmd :cmd :INFO/0:museBypass_to_epic_oru_pool:11/19/2015 17:54:24] Doing ‘resend’ command with args ‘ob_post_tps data 5120 /tmp/deferredMuseMsg_29422_1447973610.txt nl’

      [cmd :cmd :INFO/0:epic_onbase_ob_cmd:11/19/2015 17:54:24] Inrecoverable socket error.  Closing connection.

      Have any of you seen anything similar?  This same function works properly on my CL 5.6 engine.

      Jeff Dinsmore
      Chesapeake Regional Healthcare

    • Creator
      Topic
    Viewing 2 reply threads
    • Author
      Replies
      • November 20, 2015 at 1:36 pm #83323
        John Mercogliano
        Participant

          Hi Jeff,

             I can’t say if it was different before 5.7 but I’ve always had to add an ampersand so it runs in the background from any tps command.  My understanding of how this works.  Since the exec blocks until it returns, the engine process does not let monitord take over to actually process the command you are sending it.  Exec’ing it in the background should allow the event scheduler to give the monitord time to take control and run the command.

          Hope this helps,

          John Mercogliano
          Sentara Healthcare
          Hampton Roads, VA

        • November 20, 2015 at 1:39 pm #83324
          Rob Abbott
          Keymaster

            Jeff if you are trying to talk to the same process that the UPoC is running in, the process will be blocked by the exec.  So the command thread does not have a chance to run and respond to the resend command.

            The best way to work around this is to exec the command in the background by appending an ampersand to the end of the hcicmd.

            Rob Abbott
            Cloverleaf Emeritus

          • November 20, 2015 at 2:04 pm #83325
            Jeff Dinsmore
            Participant

              Bingo!

              I hadn’t thought of that…

              My usage of this method had always been in a separate process, so I didn’t run into this problem.

              Since I really want to handle any errors properly – rather than just dumping the process into the background – I moved this function to a different process and it’s working as desired.

              Thanks for the quick responses!

              Jeff Dinsmore
              Chesapeake Regional Healthcare

          • Author
            Replies
          Viewing 2 reply threads
          • The forum ‘Cloverleaf’ is closed to new topics and replies.