hcimsiutil -Z (Again)

[garry r fisher]

Hi,

I have an interface that has recovery enabled on both threads. The outbound thread is currently down because the third party are not ready yet. When I checked the number of messages yesterday on the route (not the thread) there were 6000+ messages queued. This morning the processes were shutdown so a backup could take place and hcimsiutil -Z run to initialise the counters. When I now look at the route there are only 700+ messages queued. The outbound thread has not been started so where are my other 5000+ messages? Are they still queued and if so will they go across the interface once the outbound thread is restarted.

UPDATE: Just been advised by the client that no reset took place – Now I am worried – Where has my data gone?

Cloverleaf 5.3 running on AIX if it makes a difference.

Regards

Garry

Topic

[Jim Kosloskey]

Garry,

Could it be the hcimsiutil zerod the stats?

Check the Recovery DB and see what it says.

Jim Kosloskey

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

[garry r fisher]

Jim,

From checking the log file hcimsiutil was not run on this interface. looking at the inbound thread I can see 10000+ messages xlated but on the route I can only see 3000+.

I have logged this with Quovadx as it is very disconcerting to ‘lose’ this data.

We have also checked the recovery db and can only see the 3000+ messages.

Regards

Garry

[James Cobane]

Garry,

Do an ‘hcidbdump -r -s 7 -d yourdestthreadname’ to see the messages in the recovery database that are post-xlate queued; you can pipe the output to wc to get a count (subtract 8 for the header info).

Hope this helps.

Jim Cobane

Henry Ford Health

[Michael Hertel]

Garry,

Your first message indicates 700+, your second message indicates 3000+.

It could be that the messages are taking a while to requeue themselves.

What is your count now? Did they ever show up again?

You could also look at topas to see if there is a job thrashing around to catch up.

-mh

[Russ Ross]

I have found the message counts displayed by the GUI/IDE to be unreliable as you noted with excitement, especially after doing

hcimsiutil -Z

If I want the true story I use hcidbdump -r commands much like Jim Cobane pointed out already.

The good news is that even though the GUI/IDE display of message count has given me heart attacks like the one you just had, I’ve never experienced any message losss as a result of hcimsiutil -Z.

I do recall one case of unexpected message loss I encounter but that was a result of me doing a resend to an outbound thread and lossing them when the outbound thread was recycled.

In other words, hcimsiutil -Z can make it look like messages are lost but nothing really gets lost; where as, using the resend feature even with recovery DB turned on can result in message loss if threads get recycled  before delivering the resend messages.

I’ve also found it prudent to recycle threads after all resend messages have been delivered because on occasion the normal inbound messages would not flow until I recycle the threads.

Another thing about the recovery database that confused me until I went to level II training is that for the most part it only makes sense to turn recovery database on for inbound threads.

If you want to understand that statement then turn off recovery database on the inbound thread and turn it on for the outbound thread, then let the messages que on the outbound thread, then start and stop the interfaces and your messages will all be gone.

Now reverse the process by turning recovery on for the inbound thread and turn recovery off for the outbound thread, then let messages que on outbound thread, then cycle interfaces and messages will all be preserved nice and safe.

To get the full depth of why, I will leave that up to the level II instructor.

PS:  As far as I know, none of our prodcution outbound threads have recovery database turned on but all of our inbound threads in prodcution do have recovery DB turned on.

Russ Ross
RussRoss318@gmail.com

[Michael Hertel]

When you “enable recovery” on a thread it writes any message that the protocol driver hands to it to the recovery database.

This makes perfect sense on inbound threads because the message has to make it’s journey thru the engine to one or many outbound threads.

The protocol driver on outbound threads is most likely going to hand an acknowledgement message to the thread which most times do not need to be saved to the recovery database as it will be killed immediately.

If you were routing the acknowledgement message back to the source thread, you might want to have this on.

Also if you have a conversational bidirectional interface like a query interface, you would probably want to enable recovery.

Hope this helps.

-mh

[Author]

Replies