Rebus FileSystemMessageQueue

2
votes

I discovered Rebus contains FileSystemMessageQueue. It seems too great to be true so I wanted to ask few questions about it :)

  1. Is it thread-safe/process-safe

  2. Is it transactional

  3. Why it uses JSON as serialization format (doesn't it add limitations to POCOs in comparison to binary serializer?)

  4. Could it work as separate without bus? (just as separate dll, not service)

  5. For small amount of messages, could it be replacement of MSMQ? I mean how it could be compared to MSMQ if we speak about local (not-networked), not resource-intensive messaging? would it be as good as MSMQ?

Thanks in advance

1
rebus

1 Answers

4
votes

The FileSystemMessageQueue started out as a fun experiment because I wanted to use Dropbox as a transport - which actually seems to work, but I have not tested it in any way, except from making the transport pass Rebus' usual transport contract tests and show it off at a couple of user group meetings and such :)

Therefore: Please understand that you'll be the one testing the transport, and if you do use it you'll almost immediately be the one in the world with the most experience in using it :)

</disclamer>

1) The transport keeps track of which message files are currently being handled to ensure that the same file is not being received twice, so you can safely have multiple threads receiving messages in the same endpoint.

You cannot have do competing consumers though, because there's currently no locking that can span multiple processes (could probably be done though, by using the OS to lock the files and keep the file handle for the time it takes to handle the message).

2) No. It satisfies the same at-least-once delivery guarantee as all the other transports in Rebus, but it is not transactional and it is not capable of committing its work atomically.

I've made the transport postpone the actual writing of the outgoing messages to the point after you've done your own work in your message handler, so messages won't be visible to recipients too soon - but in theory you could run into a situation where a bunch of outgoing messages were sent, and then the deletion of the received message file fails, which will result in receiving the same message again - that's why it's called "at least once" ;)

3) It uses JSON because that's an easy way to write an object to a file (even though the actual message body is serialized and encoded using the configured serializer).

4) ??? I don't understand your question :)

5) Yes and no - I guess that it would be just as good as MSMQ if we speak about local and not resource intensive messages.

I haven't performed any load tests, but I'm guessing it will be much slower than MSMQ regarding message volume. I do think that it is capable of transferring messages that are much much bigger than MSMQ though, because MSMQ still has (to my knowledge) a hard upper cap of 4 MB per message.