Removing a failed message from front of queue

This topic has 6 replies, 4 voices, and was last updated 6 years, 10 months ago by Lina Patel.

Creator

Topic
December 20, 2016 at 12:03 am #55274
Elisha Gould
Participant
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?
Creator

Topic

Viewing 5 reply threads

Author

Replies
- December 20, 2016 at 5:01 am #84773
  Charlie Bursell
  Participant
  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?
- December 20, 2016 at 5:50 am #84774
  Elisha Gould
  Participant
  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.
- December 20, 2016 at 6:21 am #84775
  Charlie Bursell
  Participant
  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.
- December 20, 2016 at 7:33 am #84776
  Elisha Gould
  Participant
  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.
- December 20, 2016 at 11:03 pm #84777
  Robert Milfajt
  Participant
  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
- February 26, 2018 at 8:37 pm #84778
  Lina Patel
  Participant
  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

Viewing 5 reply threads

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