One other thing. It probably makes sense to install the counters outside of the call to .Enable and likely something that will only get executed from an install action inside the bus.
On Sat, Mar 26, 2011 at 9:07 AM, Corey Kaylor <[email protected]> wrote: > Looks good so far. > > 1) Personally, I would opt for the breaking change by adding a Start > method. > > 2) I think this will work fine for now. We can likely tweak the build > script to elevate if needed. > > 3) Probably not using QueueManager for the sending and instead use a pseudo > Sender that throws for this would work. > > On Wed, Mar 23, 2011 at 2:33 PM, Ken Baltrinic <[email protected]>wrote: > >> 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. >> >> > -- 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.
