Hi Chelios, Isn't the LevelDB plugin enough for your use case then? No fuss, no connections, no distribution, and it is quite fast.
-Endre On Tue, Feb 16, 2016 at 12:04 PM, Chelios <chelios.banda...@gmail.com> wrote: > Hey Guys, > > Sorry didn't get any notifications about your replies in my email. Thank > you so much for your replies guys. Arno, you are right I should not be > building my own database but I was just planning on storing the State of my > actors locally (json files) instead of having it in memory in the Actor > using better-files <https://github.com/pathikrit/better-files> and > nothing more. If it gets anymore complicated than that I know I am doing > something wrong. > > And incase of an actor crash/exception or anything wrong, that Actor gets > restarted (on another machine or the same machine) and the State will be > rebuilt from the distributed Eventstore by replaying the Events ignore the > existing State on disk. The only reason to save the State to disk in a file > (may be in json) is to not use memory as much because AWS seems to charge > alot for memory hungry machines and I can afford to have all the States of > all the Actors in memory. I know I have to stop inactive Actors after some > time but what if I could stop inactive Actors and also store their State on > disk ? > > The reason not use a local database store like Postgres is to keep the > application simple. I don't need indexing or the overhead of managing > connection. Just need to write the State to a file and read from the file. > And incase of a crash, rebuilt the state by reading the events from Kafka. > > Michael I will surely give this a try :) ... I think I will be able to do > this may in 10-20 lines of code in my current Actor trait using > better-files library. Will report back :) ... > > Someone also suggested me to store the State of the Actors in Redis which > flushes the data to disk after certain time to free up the memory. Any > thoughts ? > > > > > On Saturday, February 13, 2016 at 5:14:47 AM UTC+11, Michael Frank wrote: > >> the biggest issue i can think of is that you have a risk of data >> inconsistency. for example: >> >> 1. a customer sends a command to your actor >> 2. the actor processes the command, persists an event (writing its state >> locally), and replies to the customer >> 3. before the actor can flush the event to the remote database, it >> crashes. >> 4. you revive the actor on a different host (say the original host needs >> maintenance) and the new actor incarnation loads the state from the remote >> database >> 5. now the event from step 2 has disappeared. >> >> whether or not this possibility is ok depends on your business >> requirements. >> >> i agree with Arno that the cost/benefit tradeoff is not worth it. are >> you really so memory constrained that you need to write all this code? >> will writing to local storage really be that much faster than writing to a >> database? keep in mind that for local storage in order to maintain >> consistency you'll need to fdatasync() for every event, whereas with a >> distributed database you can get away with writeback as long as you write >> to some set of nodes W where W > 1. >> >> but you should quantify and measure it if you don't believe me :) >> >> -Michael >> >> On 02/12/16 00:08, Chelios wrote: >> >> Guys !!! Any help ? >> >> On Thursday, February 11, 2016 at 1:23:59 AM UTC+11, Chelios wrote: >>> >>> Hi Guys, >>> >>> I've got an Eventsourcing & CQRS based application. Not using DDD or >>> Akka persistence (because of certain restrictions). >>> >>> Has anyone tried storing the *State* of an *Actor* to local file system >>> instead into a remote database (Like snapshotting in Akka-persistence) ? >>> >>> I was thinking of doing the following >>> >>> 1. *Command* arrives at *ActorA* >>> 2. *ActorA* checks if it has a serialized *State* on local file system, >>> if yes, it de-serializes the *State* and processes the *Command*, and >>> then *ActorA *flushes it's *State* to disk holding only directory >>> reference to the updated local serialized *State*. >>> 3. If *State* does not exists on local file system then it replays all >>> *Event*s from the database, process the *Command*,and then *ActorA *flushes >>> it's *State* to disk holding only directory reference to the updated >>> local serialized *State*. >>> >>> I see the following benefits in doing this >>> >>> 1. Much less memory usage since the state is not being kept in >>> memory. >>> 2. I don't have to worry much about killing Actors in real time >>> since the State is only holding a String which is a reference to the >>> locally serialized State's location and creating Actors is cheap. >>> 3. Reduced trips to the database. >>> 4. It's faster to read data locally since we know the location of >>> the Serialized State, so probably help in building a speedy app :) >>> >>> Am I seeing this right ? Or there are some problems that I have not >>> thought of ? Any experience with this ? >>> >>> Chel >>> >> -- >> >>>>>>>>>> Read the docs: <http://akka.io/docs/>http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: >> <https://groups.google.com/group/akka-user> >> https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to akka-user+...@googlegroups.com. >> To post to this group, send email to akka...@googlegroups.com. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - Reactive apps on the JVM Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
