inline On Thu, Apr 2, 2009 at 2:15 AM, Matt Burton <[email protected]> wrote:
> > 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? > Purge isn't implemented yet :-) Ideally, I want to maintain the most recent X number of messages. > > 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? > Each Send that is done is done by opening a TCP connection. That means that we give the NLB chance to redirect the call to some other server. > 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? You aren't missing anything, no. The problem is that HTTP only gives you request/response. That is not enough for our needs, we need to have a 4 way request/response, and TCP is the only way to do so. Theoretically, we could do that with multiple HTTP calls, but that is where NLB comes into play, we cannot really guarantee that two consecutive calls will end with the same destination server. > 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. For additional security, we can probably wrap the NetworkStream with a CryptoStream, that would give us an encrypted channel to talk over. > 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... Rhino Queues is currently setup to run as embedded, so it would run as part of your application process. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
