I have noticed two of our inbound ORM threads have a depth of -1 when I look at the thread in “list” mode of the network monitor. If I use the gui in network monitor under status I do not see anything queued. Any ideas where the -1 is coming from 😕
What you have observed is an ‘anomaly’ of the MSI Stats.
It happens from time to time. I once knew why but it happens rarely enough and was unimportant enough that I don’ recall the reason.
As far as I know there is no corrective action to take.
In a previous life, I was asked to write something to dump the stats to a delimited file. The -1 was undesirable and so it was decided to make a -1 0 because (based on the research then) they were functionaly equivalent.
Thanks,
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
Weird. I have some threads in our testsite that have -83 and -33 in the depth. At any rate anyother questin, I have inbound thread from our ADT system in our testsite that sends data to a couple of outbound test system that are not being used right now. How do I go about dumping the queued messages if the recovery database is turned off? This there some hci command for this?
There are many ways to do that. But what i have done in the past is just put somewhere in the process a proc like hcitpskill to get rid of the message. Then remove it when that system is ready to start testing again. Or you could just redirect the protocol to /dev/nul or some other such thing.
If the recovery database is turned off (on both the inbound & outbound threads), then I believe just bouncing the process(es) will clear the messages. If not, then you can use the hcidbdump command to clear the messages from the recovery database, and then bounce the process(es). If you want to keep messages from building up in the recovery database for these threads, then change the protocol of the outbounds to file /dev/null, or add the ‘hcitpsmsgkill’ proc to KILL the messages on your route.
.
.