I like what you've proposed, but wanted to throw in a couple comments / ideas for discussion. If counts are primarily what concerns you (meaning you don't really want to inspect message contents) do performance counters make more sense? I know you mentioned that it may be useful for MSMQ, but equally might be said about being useful outside of RSB. Should it be aware of RSBs use, or should it be able to categorize based on subqueue as you've described?
On Fri, Mar 18, 2011 at 5:44 AM, Ken Baltrinic <kbaltri...@gmail.com> wrote: > This is a continuation of a previous thread (http://groups.google.com/ > group/rhino-tools-dev/browse_thread/thread/56120f799262c148#), > specifically to focus on design that Ayende recommended. My time to > work on this is going to be episodic but it is something that we need > and I have some time, so I wanted to start a discussion on it. > > To keep things simple I would like to start out with just the > following use cases > Message Sending: > - Get a count of all unsent messages optionally grouped by > destination endpoint. > > Message Receiving: > - Get a count of all arrived but unprocessed messages. > - Get a count of all failed messages. > - Get a count of all discarded messages. > > Our primary interest in doing this is for RSB with Rhino-Queues as > MSMQ has its own monitoring facilities. However, there would be > advantages to using this for MSMQ as well. > > If all we want to do is count messages at the transport level this > does not appear like it would be too difficult to do. Ultimately we > may want to look at reporting on bus-level messages and being able to > filter by things like message type. That will be more difficult so I > don't want to go there at this time. > > As for the interface, Ayende has suggested a RESTful interface similar > to that used by RavenDB. My idea is to first implement an in-process > C# interface (call it for example IServiceBusManager) to give the host > process access to this information for starters and testing purposes. > Once that part is working, a RESTfull HTTP service can be added on top > of it. > > Under the hood, my initial thought is to implement IServiceBusManager > as an IMessageModule and extend ITransport to provide the needed > information from the underlying queue. > > This is just my first stab at some requirements and an approach. I am > open to ideas. > > --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 rhino-tools-dev@googlegroups.com. > To unsubscribe from this group, send email to > rhino-tools-dev+unsubscr...@googlegroups.com. > 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 rhino-tools-dev@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
