Very slick stuff - loving it. >From a debugging perspective that's a great idea, having the message history maintained automatically - but what about purge semantics? I don't have any knowledge around Esent - how is the lifetime of the data that is stored managed?
You mentioned as one of your goals that this would be load balancer friendly - as I'm not as knowledgeable in the low level details here, what characteristics of RQ make it so? You had also mentioned the use of HTTP originally on the NSB list, but this is making a direct TCP connection? Or am I missing something? One of the problems I'm facing is typical - hosting wants to have a minimal number of ports open on the firewall and they would prefer that all traffic originating from the DMZ is secured via SSL, so they have a minimal attack surface to deal with. So we started looking into MSMQ over HTTP but found it to be lacking in too many ways... With this setup it appears that I would be setting up a queue receiver (per server running as a Windows service? per service in process?) listening to a given port and then I'd have to open that up in the firewall. Please correct me if I'm missing something obvious here... Thanks, Matt On Wed, Apr 1, 2009 at 9:27 PM, Ayende Rahien <[email protected]> wrote: > Yes, currently we already have a way to track the actual message content. > (with a small twist, unlike MSMQ, we are keeping messages around after they > were sent or processed, this make debugging much easier). > Count of messages in queue is there as well, though not exposed. > I intend to create a small REST API that would allow you to plug into this > as well. > I would gladly accept any contribution that you can think of. > For myself, I think that one major contribution would be just a viewer app, > to aid in debugging what is going on. > > On Thu, Apr 2, 2009 at 12:13 AM, Corey Kaylor <[email protected]> wrote: >> >> I'm really liking this direction. Another question if you have time. >> >> MSMQ administration is a pain. Do you plan to add administrative functions >> into the api? For instance, if I want to build a replacement for the MSMQ >> administration utility, will this be directly possible for both local and >> remote administration? >> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
