Message undeliverable within retries (405)

[Gene Millard]

We are getting messages in the error database due to the following error: Message undeliverable within retries (405).  My question is do these messages stay in the recovery database and get resent later or do they get moved to the error database and have to be resent?

Retries is set to 3

Interval is set to 10

Gene

The Guthrie Clinic
Sayre, PA

Topic

[Jim Kosloskey]

Gene,

To answer your immediate question I believe the are transferred to the Error DB and need to be resent from there (or deleted from there and resent from SMAT).

I have a question – Do you have any procs in place for handling the timeouts?

What release of Cloverleaf?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Gene Millard]

We are on version 6.1.

Our timeout handling is set to Resend OB Message.

No procs in place.

Would setting the Retries to -1 prevent this from happening?

The Guthrie Clinic
Sayre, PA

[Jim Kosloskey]

Yes -1 would do that but it would now wait forever. So you need something to catch an unacceptable wait. While waiting your Pending Queue will grow.

If this is a periodic situation where sometimes the receiving system can take up to say 30 seconds then you can just set the wait time to 30 seconds.

You could still get the situation just less frequently (perhaps never).

In talking with the reciving system and by observation you should be able to come up with a ‘happy’ number for the wait time.

But life does happen. If you never want the messages to get to the ERROR DB you can write your own proc to do what makes sense to you. Like save to a file (and KILL it), email some people, stop the thread, or whatever.

I have found that setting a proper wait time usually gives acceptable results.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Gene Millard]

I will try setting the wait time to 30 and go from there.

We are not good enough in tcl to be able to write a proc.

The Guthrie Clinic
Sayre, PA

[Charlie Bursell]

I’m a bit confused.  Where do you select “Resend OB message” without a proc?

If you select Await Replies it will, by default, assign hcitpsmsgkill which will simply KILL any replies and not do resends.  I would think you would need something like cl_check_ack to do the resends after the timeout, assuming these are HL7 messages.  It will attempt 3 resends then send the message to the Error DB if not successful.

I would also suggest you go under the Inbound tab of your OB thread and select “Outbound Only”.  This will prevent any messages coming in when not waiting replies.  Much more ergonomic!

There is no real hit in increasing the wait timeout if you think the response will be slow.  The engine will still send messages as fast as it gets a response.  I have had occasion where a vendor wanted to update his database before sending a response to set the timeout to 300.

[Gene Millard]

You are correct we do have the hcitpsmsgkill proc in place.  Sorry about the confusion.  I was thinking that they were asking about one in the reply Generation area.

We have Outbound Only checked.

On the outbound tab.

In the Outbound Data section we have

Retries 3

Scan 30

In the Inbound Replies section we have

Await Replies checked

Timeout 30

hcitpsmsgkill

HL7

Which one of these would you set to 300?

I would like if possible to keep messages from going to the error database.

Gene

The Guthrie Clinic
Sayre, PA

[Jim Kosloskey]

Gene,

Set the timeout to a higher value. 300 if you think that is enough time.

As I said earlier though, if the receiving system exceeds 300 seconds you will have messages go to the Error DB. While that may happen less frequently, when it does the message has not been delivered.

Moreover in my experience this can be an expression of a systemic issue on the receiving end and every message following until the systemic issue is resolved will likely time out thus more message in the Error DB.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies