> Purge isn't implemented yet :-) > Ideally, I want to maintain the most recent X number of messages.
Or messages newer than a configured date - would be nice to have both options (configurable w/sensible defaults) to satisfy the needs of any environment. > 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. Makes sense - thanks for clarifying. > For additional security, we can probably wrap the NetworkStream with a > CryptoStream, that would give us an encrypted channel to talk over. Good deal. > Rhino Queues is currently setup to run as embedded, so it would run as part > of your application process. My main concern here is something which I take for granted in an MSMQ-based solution - if my service isn't there the caller can still write to the queue and my service will get the message when it comes back up. I guess there really isn't anything about RQ that prohibits a dedicated process, you're just saying that right now it's geared towards in-proc? On Thu, Apr 2, 2009 at 4:41 AM, Ayende Rahien <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
