When the MSDE workload governor is engaged occasionally because of a few times when there are more than 8 concurrent SQL accesses, Praetor's filtering may appear sluggish. Eventually things will return to normal as inbound message volume tapers off. When the workload governor is constantly being engaged, then Praetor filtering may appear to stop because no new entries are being logged into the SQL database.
You should obtain MSDE statistics of the concurrent access limit by using the Microsoft OSQL command line tool. Since Praetor is installed with the MSDEstats.SQL script file in its main folder, invoke the command:
OSQL /E -i MSDEstats.SQL
What appears will be something like the following:
Concurrency violations since 2004-08-04 09:47:24.060
1 2 3 4 5 6 7 8 9 10-100 >100
19643 5299 3839 1331 1275 1188 1520 2437 2387 25744 25744
Concurrency violations will be written to the SQL Server error log.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
The first row of numbers (in green) are column headings for the number of excess concurrent access beyond the limit of 8. The second row of numbers (in red) show how many times MSDE found that number of excess concurrent access attempts had happened since the date and time of last reset.
The above example was obtained on Aug 6th, only two days after last reset and shows frequencies that are extremely high, especially for the cases in the last two columns on the right for 10-100 and >100. These statistics are telling us that the message volume was so high that MSDE found too many concurrent access over the two-day period. Indeed, the workload governor was delaying Praetor from accessing its database for so long a time that it could not filter the message in the allotted 60-second (default) period as all threads were busy waiting for MSDE. As a result of this situation, the Windows Event Log for applications will have numerous entries from the source prXPSink. Opening any such entry will show the following details describing the unavailability of message submission threads.
Seeing an entire series of such Windows application log entries proves that MSDE is now a severe limiting factor and you need to use SQL Server, not its free desktop edition. To preserve your Praetor log and token databases you will need to migrate them to SQL Server.
If your MSDE is sufficient for your email volume, the frequency shown in red would be low, and they should decrease going from left-to-right, something like the following:
violations since 2004-06-23 08:05:22.055
1 2 3 4 5 6 7 8 9 10-100 >100
196 52 38 13 7 11 5 1 1 2 0
These numbers show that there were some spikes in messaging volume, but MSDE would eventually return back to normal. Never did MSDE find so many concurrent accesses as to cause Praetor to wait for very long even as it delayed the fulfillment of the SQL database access.
You can reset the MSDE statistics by using the file MSDEstats-reset.SQL located in the Praetor G2 folder. Invoke it as follows:
OSQL /E -i MSDEstats-reset.SQL