Raven MQ – The Real API
Originally posted at 11/17/2010
This is now a passing test…
public class UntypedMessages : IDisposable { private readonly RavenMqServer ravenMqServer; private readonly RavenConfiguration configuration; public UntypedMessages() { configuration = new RavenConfiguration { RunInMemory = true, AnonymousUserAccessMode = AnonymousUserAccessMode.All }; ravenMqServer = new RavenMqServer(configuration); } [Fact] public void Can_get_message_from_client_connection() { using(var connection = new RavenMQConnection( new Uri(configuration.ServerUrl), new IPEndPoint(IPAddress.Loopback, 8181))) { var manualResetEventSlim = new ManualResetEventSlim(false); OutgoingMessage msg = null; connection.Subscribe("/queues/abc", (context, message) => { msg = message; manualResetEventSlim.Set(); }); WaitForSubscription(); ravenMqServer.Queues.Enqueue(new IncomingMessage { Data = new byte[] {1, 2, 3}, Queue = "/queues/abc" }); manualResetEventSlim.Wait(); Assert.Equal(new byte[]{1,2,3}, msg.Data); } } private void WaitForSubscription() { // not important } public void Dispose() { ravenMqServer.Dispose(); } }
Unlike the previous posts, which were more design and up front, this post shows working code. I am still not completely happy witht his, mostly because of the RavenMQConnection ctor parameters, but I can live with this for now.
Comments
RavenMQ is using RavenDB as underlying storage engine. Can I assume that messages are persisted in the document database when RunInMemory=false? As it is (and has roughly the same performance as rhino.queues) I have a ton of usages for it..
With a simple wrapper you can almost use it as an dropin for the Queue <t class. The wrapper can verify if the message is of type T.
Dave,
RavenMQ uses the same storage technology as RavenDB, not RavenDB.
But yes, it persists to disk.
Seems that you want to run your tests as fast as possible, using ManualResetEventSlim:> Does internals of RavenMQ use it as well?
Scooletz,
Actually, no. We don't do any locking inside RavenMQ
Ayende, thanks for that clarification. I know it's early, but do you have any timeline on a alpha release?
1) What is WaitForSubscription? Why is it required? Why do you say it's not important?
2) Why are IncomingMessage and OutgoingMessage reversed? From the perspective of consumer, shouldn't you Enqueue OutgoingMessage and Subscribe for IncomingMessage? Did you name them from the perspective of the queue server?
What happens if you don't wait for the subscription? The message should still be handled once the subscription is set up, shouldn't it?
Dave,
I hope to have something out in a month
zvolkov,
1) WaitForSubscriptions is there because I still didn't implement immediate queue check,mostly.
2) Mostly because you are looking at the very low level API. And yes, they are from the POV of the queues server
Configurator,
Yes, but that isn't implemented yet.
Comment preview