state messages own component thread
State Messages today share SMSExec thread with Status messages. State messages are a lower priority. Even though State messages process super fast, we have been in the issue where we have 300,00 status message backlog and and 3.4 million state message back log. Only way to get the state messages to process first is to move all the status messages from the inbox, allow state messages to process and then slowly add the status messages back in as ConfigMan can not handle large amount of files in those inboxes.
So we are looking to allow State Messages, it own thread so this is not an issue when a backlog does occur. State Messages would never be the issue and we can concertrate on just status messages.
State messages are processed by the SMS_STATE_SYSTEM component, and status messages are processed by the SMS_STATUS_MANAGER component. Both use independent threads and inboxes, and should operate independently. A state message backlog should not be causing delays for status message processing unless there’s a SQL bottleneck or unknown product issue.
I’d recommend working with support to better understand what’s happening here.