I must have miss understood you initially then. What are your thoughts on the idea of RQ providing performance counters?
On Mar 18, 1:52 pm, Ayende Rahien <[email protected]> wrote: > What I actually spoke of was adding HTTP service inside RQ, which expose the > RQ information externaly. > > > > > > > > On Fri, Mar 18, 2011 at 7:45 PM, Ken Baltrinic <[email protected]> wrote: > > So to reply to both Ayende and Corey, > > > 1) Yes I believe at some point we are going to want to know what is > > inside the messages, esp. for messages in the error queue, but before > > we go looking into the queue for particular messages, we need to know > > there is a problem, and for that just counts should do. Your idea of > > publishing queue metrics as performance counters is interesting in > > this regard. That may be a very worth while consideration. > > > 2) In the original post, my initial intent was to implement this > > solution at the Rhino-Queue layer, not the RSB layer, but Ayende > > argued for a restful service hosted in RSB. Perhaps I didn't make the > > objectives clear initially. > > > So my current thoughts are 1) look into implementing performance > > counters inside of Rhino-Queues as a first step that will provide the > > health monitoring that is our immediate need. 2) Add some ability to > > dig into the queues and examine messages later should the need arise > > and debate the merits of doing it at the RQ vs RSB layer at that > > point. > > > On Mar 18, 12:45 pm, Ayende Rahien <[email protected]> wrote: > > > You can't do that with just RSB, you have to implement that inside rhino > > > queues, and if you really want that on MSMQ, as a service that exposes > > that > > > on top of the MSMQ API. > > > RSB can't be relied on to know what is in the queues, there may be other > > > sources feeding infromation there. > > > > On Fri, Mar 18, 2011 at 1:44 PM, Ken Baltrinic <[email protected]> > > 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 [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. -- 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.
