hcidmd behaves differently in UPOC vs Tcl shell

[Jeff Dinsmore]

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

Topic

[John Mercogliano]

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

[Rob Abbott]

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

[Jeff Dinsmore]

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