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.
