I have moved ahead with implementing this based on the design I described above and have pushed my in progress work to my fork on GitHub (https://github.com/kbaltrinic/rhino-queues/tree/perf-counters) for review. Currently I have a few concerns.
1) I am currently initializing performance counters by a call to QueueManager.EnablePerformanceCounters(...); Since this call is made after the manager is constructed, send and receive operations are already in progress and there are thus threading concerns with the PerformanceMonitor.SyncWithCurrentQueueState() method as its trying to hit a moving target. I would like to hear some ideas on what people think may be the best way to solve this. I think my favorite option is to add a override to QueueManager constructor that takes a new "ConfigurationData" object that can be used to pass in configuration information. This way, if preformance motinoring is desired, it can start up before the send and receive threads do. Another option is to add a Start method to the QueueManager and not start the automatically, but that is a breaking change, unless we add a autostart switch to the constructor that defaults to true. Third is some means of thread synchronization. 2) The integration tests in the Rhino.Queues.Tests.Monitoring.EnablingPerformanceCounters fixture required admin rights in order to work as only admin accounts can create and delete Perf Counter Categories. I am not sure how that requirement should be handled in the context of this project. 3) The MessageQueuedForReceive_EventNotRaised_IfReceiveAborts test in the Rhino.Queues.Tests.RaisingReceivedEvents fixture is currently set to skip because, other than coding a throw statement into the Sender class and removing it after the test, I can't figure out a set up the needed conditions for this test. Lastly, the final piece of this implementation that I have yet to tackle is setting up the PerformanceMonitor class so that it participates in transactions. Currently for example, if a message is sent, the Unsent Messages counter gets incremented immediately and does not decrement if the tx rolls back. Same thing for Receive, MoveTo and EnqueueDirectlyTo actions. I have a pretty good idea of how I intend to handle this. Just throwing it out there as an FYI of work yet to be done. --Ken -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
