Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Raven MQ – The Real API

time to read 3 min | 589 words

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);

    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;


            ravenMqServer.Queues.Enqueue(new IncomingMessage
                Data = new byte[] {1, 2, 3},
                Queue = "/queues/abc"


            Assert.Equal(new byte[]{1,2,3}, msg.Data);

    private void WaitForSubscription()
        // not important

    public void 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.



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.

Ayende Rahien


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?

Ayende Rahien


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?

Ayende Rahien


I hope to have something out in a month

Ayende Rahien


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

Ayende Rahien


Yes, but that isn't implemented yet.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats