Add read only mode to journals

[patelh]

Added readOnly as a property to journal props and updated tests to test read only mode.

[krasserm]

Hi Hiral,

thanks for your contribution. Why don't you simply decorate the journal actors (during instantiation with actorOf) with a special actor (say ReadOnlyFacade) if readOnly is true. The ReadOnlyFacade actor simply drops all write commands and only forwards read commands to the journals actor. This would have the following advantages:

• no need to change the code of existing journal actors
• decoration could even be done generically in JournalProps.createJournal (i.e. check the readOnly setting here and only decorate the created journal actor with a ReadOnlyFacade actor if readOnly is true).

Maybe I'm missing something but wouldn't this dramatically simplify things?

Cheers, Martin

[patelh]

Sure, we can try using a mixin at construction time. I will refactor to do this. However, using a base type which provides the write path methods may be a better separation of concerns then just having a facade on top of any Actor which intercepts all messages and redirects write specific commands to do nothing.

I also think we should keep the Writer trait introduced in SynchronousWriteReplaySupport which is just inspired by the AsynchronousWriteReplaySupport Writer (a better separation of concerns).

[krasserm]

I didn't mean using a mixin at construction time, rather a separate actor (read-only facade) that has a reference to a journal actor. This facade actor only forwards read commands.

[krasserm]

I also think we should keep the Writer trait introduced in SynchronousWriteReplaySupport which is just inspired by the AsynchronousWriteReplaySupport Writer (a better separation of concerns).

This will break existing external journal implementations.

[patelh]

Hm, using another actor to essentially filter on write specific commands is less efficient then building it right into the write path at construction time of journal. But yes it is less invasive but feels more of a bandage or duct tape on top.

Existing external journal implementations that use the SynchronousWriteReplaySupport would break, you're right. Maybe we can create a new trait which has similar abstractions to the AsynchronousWriteReplaySupport and create an implementation of SynchronousWriteReplaySupport on top of the new trait without changing method signatures. Then it would be easier to deprecate SynchronousWriteReplaySupport in favor of the new trait with better separation of concerns. What do you think?

[patelh]

Nevermind, I think this is a moot point since all this will be in akka-persistence. I'll work on a less invasive patch.

[krasserm]

Hm, using another actor to essentially filter on write specific commands is less efficient then building it right into the write path at construction time of journal.

You can ignore that overhead relative to the much higher IO overhead

But yes it is less invasive but feels more of a bandage or duct tape on top.

Why? This is idiomatic actor design.

Then it would be easier to deprecate SynchronousWriteReplaySupport in favor of the new trait with better separation of concerns.

What concerns do you want to separate and what is the advantage over the existing implementation?

[krasserm]

Nevermind, I think this is a moot point since all this will be in akka-persistence.

In akka-persistence, there will be read-only processors (=read views) for which you can create snapshots

[krasserm]

I'll work on a less invasive patch.

Great, thanks!

[patelh]

What concerns do you want to separate and what is the advantage over the existing implementation?

I was mostly thinking of the Replayer, Writer and Snapshotter that are in the Async version.

[patelh]

Let me know if you'd like any other changes.

[krasserm]

Looks good, thanks a lot for your contribution @patelh

[krasserm]

Jars are now published to the Eligotech repo.

[patelh]

Awesome, thanks!