Removing a failed message from front of queue

[Elisha Gould]

For the outbound threads, there are a few threads that will either not respond or reply with the AR ack, when there should be an AE ack.

The result is that we will retry continuously until we remove the message from the queue.

Our normal process is to:

* do a pstop on the thread.

* delete the state 14/16 message from the database.

* do a pstart on the thread.

This works ok for most of the threads, but CAAWS does not handle a pstop/pstart correctly, and instead needs a process bounce.

Is there another way to remove the failing message from the queue without the pstop/pstart?

Topic

[Charlie Bursell]

I am a bit confused here.  Are you not using the recover procs?

The check_ack proc I wrote many years ago, now for some reason renamed cl_check_ack, will send a message to the Error DB if three successive AR responses or one AE response is received.

Is there some reason you don’t want to use the proc?

[Elisha Gould]

The issue with removing after a number of retries, is that there are cases where we would be dumping lots of messages, then have to replay all the messages from a point in time once the application was fixed, since they all need to be played back in order (not just the failed messages).

This is more of an issue for SOAP messages on the CAAWS, since the fault messages are returned whenever there are application/database issues.

So basically the effort to dump a message if it is causing problems is less than the effort of replaying all the messages from the time the downstream application failed.

[Charlie Bursell]

Using the proc as a model change it save messages to a file rather than the Error DB,  You then have the file to resend.

It seems to me you could also call a script to stop the process when this begins to occur.  Do not stop the thread.  If the process is busy it may time out and not stop.  Stop the process even if you have to put the one thread in its own process.

[Elisha Gould]

The main issue with putting the message in a file/error database, is that all future messages for that patient would need to be quarantined, otherwise replaying the errored message may put the details in the wrong state.

Stopping the process may work for the CAAWS cases if needed. Was just checking if there was a way of pulling a message out without having to stop it, or writing extra code in the resend handler.

[Robert Milfajt]

If you don’t care about the message or the cause and you just kill it anyway, replace TPS Inbound Reply TPS scripts with hcitpsmsgkill.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Lina Patel]

Outbound thread –

I do not have access to old tcl procs mentioned in post.

What is best approach for bypassing state 16 messages and saving to error db so remaining messages can continue processing.

Thank you!

[Author]

Replies