hcimsiutil -Z (Again)

Garry,

Could it be the hcimsiutil zerod the stats?

Check the Recovery DB and see what it says.

Jim Kosloskey

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

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

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.

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