[akka-user] Re: Using local file system to store Actor's state ?

[Chelios]

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/
>>  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.

Re: [akka-user] [Akka Stream] Exceptions in AbstractInHandler and AbstractOutHandler

[Viktor Klang]

They will fail the stage if they throw

-- 
Cheers,
√
On Feb 12, 2016 8:54 AM, "hbf"  wrote:

> Hey everybody,
>
> The documentation doesn't say how exceptions in a GraphStage's handlers (
> AbstractInHandler and AbstractOutHandler) are treated. Do they cause
> undefined behavior or will they implicitly call failStage()?
>
> Thanks!
> Hbf
>
> --
> >> 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.
>

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

Re: [akka-user] Re: Akka persistence query examples

[Patrik Nordwall]

There is a offset: Long that the query journal can implement in a way that
is suitable. Easiest is to use a timestamp, or a global sequence number if
you have that luxury (e.g. a sql database).

The Cassandra plugin is using a timeuuid (a Cassandra data type) column and
therefore supports queries with timestamp offset

or uuid offset

.

Cheers,
Patrik
​

On Fri, Feb 12, 2016 at 8:56 AM, Andrew Easter 
wrote:

> Hi everyone. Just waking up this thread with a related challenge/question.
>
> One of the objectives of Persistence Query was to address the limitation
> that a PersistentView was only able to project from a single persistence
> id. As we all know, this meant that trying to do CQRS in a DDD based system
> (actor per instance of an aggregate) wasn't possible without workarounds.
> The workaround I used was to have all my aggregate actors send (using ALOD
> trait) events on to an intermediate persistent actor, one per aggregate
> type. This meant I could create a PersistentView that could see a stream of
> all events from all instances of an aggregate type.
>
> Obviously, the above solution is a little cumbersome. Downsides such as
> having to essentially duplicate all events in the intermediate persistent
> actor.
>
> The Persistence Query introduces us to the concept of querying events by
> tag - the docs suggest this as the most appropriate method for implementing
> CQRS in a DDD based actor implementation. However, I'm struggling to
> understand how this is really fit for purpose given that there are no order
> guarantees in an eventsByTag stream, and accordingly no sequence number I
> can refer back to such that I know how far through the stream I've read.
>
> The discussion here is about persisting an offset in the view datastore,
> but how can I do that when there is no reliable seq number?
>
> Sorry if I'm not making sense! Would love to hear some ideas about how to
> deal with this.
>
> Thanks, Andrew
>
> --
> >>  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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] how to control lifetime of a sharded entity

[Patrik Nordwall]

The name of the actor is the entity identifier (utf-8 URL-encoded), i.e.
`self().path().name()`.
I don't know why you are suggesting `parent()`.

Those actors are not stopped automatically unless there is a rebalance, so
that must be something you do.

On Thu, Feb 11, 2016 at 9:52 PM, Filippo De Luca 
wrote:

> Hi Bert,
> the only way that I am aware of to get the id is using the one you have
> posted:
>
>context().parent().path().name()
>
> It is weird that the Actors get destroyed. They should not by default.
>
> On 11 February 2016 at 16:19, Bert Robben  wrote:
>
>> Hi,
>>
>> I'm trying to use sharding and that works reasonably well (my entities
>> are being created across my cluster and they respond to my requests).
>>
>> However, I notice that after each call to my entity, it is destroyed.
>> Every next call on the entity then recreates it. This is not ideal for me
>> since restarting my entity is a heavy process (I might need to recover lots
>> of state from the database). So I would like to tune the system such that
>> my entities are survive for much longer (they are perfectly suited to
>> handle many concurrent requests). Is this somehow possible with the current
>> implementation?
>>
>> Note that I use state-store-mode = ddata and I don't make use of Akka
>> Persistence.
>>
>>
>> Also, in my case it is vital for my entity to know its id, because that's
>> how it discerns itself from the other entities. The only way I've found to
>> get to the id now is to do context().parent().path().name(). That works,
>> but feels very implementation dependent. Am I missing some easier API?
>>
>>
>> thanks,
>>
>> Bert
>>
>> --
>> >> 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.
>>
>
>
>
> --
>
>
> [image: --]
> Filippo De Luca
> [image: http://]about.me/FilippoDeLuca
> 
>
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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-user] Re: how to control lifetime of a sharded entity

[Bert Robben]

Thanks Filippo. I think I figured out now what was going wrong.

I was confused between the shardId and the entityId.

shardId == context().parent().path().name()
entityId == self().parth().name()

My entities were being created again and again because I was computing the 
entityId wrongly. In my case, all messages carry an id. What I need is 
entityId = hash(messageId) and shardId = hash(entityId). However, I was 
doing entityId = messageId and shardId = hash(messageId). Therefore I was 
always creating a new entity because the messageId is unique. I've fixed my 
MessageExtractor now and everything goes as it should.

thanks,

Bert

On Thursday, February 11, 2016 at 5:36:17 PM UTC+1, Bert Robben wrote:
>
> Hi,
>
> I'm trying to use sharding and that works reasonably well (my entities are 
> being created across my cluster and they respond to my requests).
>
> However, I notice that after each call to my entity, it is destroyed. 
> Every next call on the entity then recreates it. This is not ideal for me 
> since restarting my entity is a heavy process (I might need to recover lots 
> of state from the database). So I would like to tune the system such that 
> my entities are survive for much longer (they are perfectly suited to 
> handle many concurrent requests). Is this somehow possible with the current 
> implementation?
>
> Note that I use state-store-mode = ddata and I don't make use of Akka 
> Persistence.
>
>
> Also, in my case it is vital for my entity to know its id, because that's 
> how it discerns itself from the other entities. The only way I've found to 
> get to the id now is to do context().parent().path().name(). That works, 
> but feels very implementation dependent. Am I missing some easier API?
>
>
> thanks,
>
> Bert
>

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

Re: [akka-user] Re: Using local file system to store Actor's state ?

[Arno Haase]

I guess that depends on what you are trying to achieve, e.g. what degree
of durability, consistency etc. you need.

What you describe sounds like you are basically beginning to write your
own local database. Doing that well involves *hugh* amounts of tricky
code, like ensuring data consistency in rare cases when the OS crashes /
the machine loses power etc.

Your approach also means your actor can never fail over to a different
(virtual) machine.

And talking of speed, I would be wary of guessing speed-ups without
actual measurements, especially under load.

So while you probably could get a solution based on local storage to
work, it is likely to be far more work than it looks initially, be a
pain to maintain, and is likely to fail in esoteric ways at unexpected
times ;-)

- Arno


Am 12.02.2016 um 09:08 schrieb Chelios:
> 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/
>>> 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.

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

Re: [akka-user] how to control lifetime of a sharded entity

[Bert Robben]

Hi Patrik,

Yes, I've found out my mistake. I was confusing shardId with entityId.

shardId = context().parent().path().name()
entityId = self().path().name()

(you might want to add this to the documentation, because I was confused 
for a while in how the entity would be able to know its own id)

In my app, I wanted to have entityId = hash(messageId) and shardId = 
hash(hash(entityId)). But I had it as entityId = messageId and shardId = 
hash(entityId). Because of this always a new entity was being created as 
the messageId is always different. I've now fixed the messageExtractor and 
now everything works as expected and as it should.

thanks,

Bert

PS: I thought I already sent a reply for this this morning, so if that one 
turns up again this is a duplicate ...

On Friday, February 12, 2016 at 10:48:55 AM UTC+1, Patrik Nordwall wrote:
>
> The name of the actor is the entity identifier (utf-8 URL-encoded), i.e. 
> `self().path().name()`.
> I don't know why you are suggesting `parent()`.
>
> Those actors are not stopped automatically unless there is a rebalance, so 
> that must be something you do.
>
> On Thu, Feb 11, 2016 at 9:52 PM, Filippo De Luca  > wrote:
>
>> Hi Bert,
>> the only way that I am aware of to get the id is using the one you have 
>> posted:
>>
>>context().parent().path().name()
>>
>> It is weird that the Actors get destroyed. They should not by default.
>>
>> On 11 February 2016 at 16:19, Bert Robben > > wrote:
>>
>>> Hi,
>>>
>>> I'm trying to use sharding and that works reasonably well (my entities 
>>> are being created across my cluster and they respond to my requests).
>>>
>>> However, I notice that after each call to my entity, it is destroyed. 
>>> Every next call on the entity then recreates it. This is not ideal for me 
>>> since restarting my entity is a heavy process (I might need to recover lots 
>>> of state from the database). So I would like to tune the system such that 
>>> my entities are survive for much longer (they are perfectly suited to 
>>> handle many concurrent requests). Is this somehow possible with the current 
>>> implementation?
>>>
>>> Note that I use state-store-mode = ddata and I don't make use of Akka 
>>> Persistence.
>>>
>>>
>>> Also, in my case it is vital for my entity to know its id, because 
>>> that's how it discerns itself from the other entities. The only way I've 
>>> found to get to the id now is to do context().parent().path().name(). That 
>>> works, but feels very implementation dependent. Am I missing some easier 
>>> API?
>>>
>>>
>>> thanks,
>>>
>>> Bert
>>>
>>> -- 
>>> >> 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+...@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.
>>>
>>
>>
>>
>> -- 
>>  
>>
>> [image: --]
>> Filippo De Luca
>> [image: http://]about.me/FilippoDeLuca
>>   
>>  
>>
>> -- 
>> >> 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+...@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.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
>

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

Re: [akka-user] Re: how to control lifetime of a sharded entity

[Patrik Nordwall]

I think it is documented that the entity id is the actor name. You are
welcome to contribute with clarifications with a pull request if you like.

The entity type name should be well know by your application. A constant or
you can pass it as a constructor parameter via the Props. No need to
involve grandpa.

fre 12 feb. 2016 kl. 11:43 skrev Bert Robben :

> Thanks Filippo. I think I figured out now what was going wrong.
>
> I was confused between the shardId and the entityId.
>
> shardId == context().parent().path().name()
> entityId == self().parth().name()
>
> My entities were being created again and again because I was computing the
> entityId wrongly. In my case, all messages carry an id. What I need is
> entityId = hash(messageId) and shardId = hash(entityId). However, I was
> doing entityId = messageId and shardId = hash(messageId). Therefore I was
> always creating a new entity because the messageId is unique. I've fixed my
> MessageExtractor now and everything goes as it should.
>
> thanks,
>
> Bert
>
>
> On Thursday, February 11, 2016 at 5:36:17 PM UTC+1, Bert Robben wrote:
>>
>> Hi,
>>
>> I'm trying to use sharding and that works reasonably well (my entities
>> are being created across my cluster and they respond to my requests).
>>
>> However, I notice that after each call to my entity, it is destroyed.
>> Every next call on the entity then recreates it. This is not ideal for me
>> since restarting my entity is a heavy process (I might need to recover lots
>> of state from the database). So I would like to tune the system such that
>> my entities are survive for much longer (they are perfectly suited to
>> handle many concurrent requests). Is this somehow possible with the current
>> implementation?
>>
>> Note that I use state-store-mode = ddata and I don't make use of Akka
>> Persistence.
>>
>>
>> Also, in my case it is vital for my entity to know its id, because that's
>> how it discerns itself from the other entities. The only way I've found to
>> get to the id now is to do context().parent().path().name(). That works,
>> but feels very implementation dependent. Am I missing some easier API?
>>
>>
>> thanks,
>>
>> Bert
>>
> --
> >> 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.
>

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

Re: [akka-user] Re: how to control lifetime of a sharded entity

[Bert Robben]

I'm not sure what you mean with "entity type name" and grandpa.


But I checked the docs again, and it indeed is already mentioned that the
name is the entityId. I must have overlooked that.

Bert

On Fri, Feb 12, 2016 at 12:14 PM, Patrik Nordwall  wrote:

> I think it is documented that the entity id is the actor name. You are
> welcome to contribute with clarifications with a pull request if you like.
>
> The entity type name should be well know by your application. A constant
> or you can pass it as a constructor parameter via the Props. No need to
> involve grandpa.
>
> fre 12 feb. 2016 kl. 11:43 skrev Bert Robben :
>
>> Thanks Filippo. I think I figured out now what was going wrong.
>>
>> I was confused between the shardId and the entityId.
>>
>> shardId == context().parent().path().name()
>> entityId == self().parth().name()
>>
>> My entities were being created again and again because I was computing
>> the entityId wrongly. In my case, all messages carry an id. What I need is
>> entityId = hash(messageId) and shardId = hash(entityId). However, I was
>> doing entityId = messageId and shardId = hash(messageId). Therefore I was
>> always creating a new entity because the messageId is unique. I've fixed my
>> MessageExtractor now and everything goes as it should.
>>
>> thanks,
>>
>> Bert
>>
>>
>> On Thursday, February 11, 2016 at 5:36:17 PM UTC+1, Bert Robben wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to use sharding and that works reasonably well (my entities
>>> are being created across my cluster and they respond to my requests).
>>>
>>> However, I notice that after each call to my entity, it is destroyed.
>>> Every next call on the entity then recreates it. This is not ideal for me
>>> since restarting my entity is a heavy process (I might need to recover lots
>>> of state from the database). So I would like to tune the system such that
>>> my entities are survive for much longer (they are perfectly suited to
>>> handle many concurrent requests). Is this somehow possible with the current
>>> implementation?
>>>
>>> Note that I use state-store-mode = ddata and I don't make use of Akka
>>> Persistence.
>>>
>>>
>>> Also, in my case it is vital for my entity to know its id, because
>>> that's how it discerns itself from the other entities. The only way I've
>>> found to get to the id now is to do context().parent().path().name(). That
>>> works, but feels very implementation dependent. Am I missing some easier
>>> API?
>>>
>>>
>>> thanks,
>>>
>>> Bert
>>>
>> --
>> >> 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.
>>
> --
> >> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/njCIQqOJTrw/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>

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

Re: [akka-user] Re: how to control lifetime of a sharded entity

[Patrik Nordwall]

You do something like this:
```
ClusterSharding.get(system).start("Counter",
  Props.create(Counter.class), settings, messageExtractor);
```

That "Counter" name is what I call the entity type name. I thought you were
trying to get to that via context().parent().parent(), which should not be
necessary.

On Fri, Feb 12, 2016 at 12:26 PM, Bert Robben  wrote:

> I'm not sure what you mean with "entity type name" and grandpa.
>
>
> But I checked the docs again, and it indeed is already mentioned that the
> name is the entityId. I must have overlooked that.
>
> Bert
>
> On Fri, Feb 12, 2016 at 12:14 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> I think it is documented that the entity id is the actor name. You are
>> welcome to contribute with clarifications with a pull request if you like.
>>
>> The entity type name should be well know by your application. A constant
>> or you can pass it as a constructor parameter via the Props. No need to
>> involve grandpa.
>>
>> fre 12 feb. 2016 kl. 11:43 skrev Bert Robben :
>>
>>> Thanks Filippo. I think I figured out now what was going wrong.
>>>
>>> I was confused between the shardId and the entityId.
>>>
>>> shardId == context().parent().path().name()
>>> entityId == self().parth().name()
>>>
>>> My entities were being created again and again because I was computing
>>> the entityId wrongly. In my case, all messages carry an id. What I need is
>>> entityId = hash(messageId) and shardId = hash(entityId). However, I was
>>> doing entityId = messageId and shardId = hash(messageId). Therefore I was
>>> always creating a new entity because the messageId is unique. I've fixed my
>>> MessageExtractor now and everything goes as it should.
>>>
>>> thanks,
>>>
>>> Bert
>>>
>>>
>>> On Thursday, February 11, 2016 at 5:36:17 PM UTC+1, Bert Robben wrote:

 Hi,

 I'm trying to use sharding and that works reasonably well (my entities
 are being created across my cluster and they respond to my requests).

 However, I notice that after each call to my entity, it is destroyed.
 Every next call on the entity then recreates it. This is not ideal for me
 since restarting my entity is a heavy process (I might need to recover lots
 of state from the database). So I would like to tune the system such that
 my entities are survive for much longer (they are perfectly suited to
 handle many concurrent requests). Is this somehow possible with the current
 implementation?

 Note that I use state-store-mode = ddata and I don't make use of Akka
 Persistence.


 Also, in my case it is vital for my entity to know its id, because
 that's how it discerns itself from the other entities. The only way I've
 found to get to the id now is to do context().parent().path().name(). That
 works, but feels very implementation dependent. Am I missing some easier
 API?


 thanks,

 Bert

>>> --
>>> >> 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.
>>>
>> --
>> >> 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 a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/njCIQqOJTrw/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>>
>
> --
> >> 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.
>

Re: [akka-user] Re: how to control lifetime of a sharded entity

[Bert Robben]

Ah, no. I was only using context().parent().name() because I incorrectly
thought that this was my entityId. Creating my entity props never was a
problem.

On Fri, Feb 12, 2016 at 12:31 PM, Patrik Nordwall  wrote:

> You do something like this:
> ```
> ClusterSharding.get(system).start("Counter",
>   Props.create(Counter.class), settings, messageExtractor);
> ```
>
> That "Counter" name is what I call the entity type name. I thought you
> were trying to get to that via context().parent().parent(), which should
> not be necessary.
>
> On Fri, Feb 12, 2016 at 12:26 PM, Bert Robben 
> wrote:
>
>> I'm not sure what you mean with "entity type name" and grandpa.
>>
>>
>> But I checked the docs again, and it indeed is already mentioned that the
>> name is the entityId. I must have overlooked that.
>>
>> Bert
>>
>> On Fri, Feb 12, 2016 at 12:14 PM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> I think it is documented that the entity id is the actor name. You are
>>> welcome to contribute with clarifications with a pull request if you like.
>>>
>>> The entity type name should be well know by your application. A constant
>>> or you can pass it as a constructor parameter via the Props. No need to
>>> involve grandpa.
>>>
>>> fre 12 feb. 2016 kl. 11:43 skrev Bert Robben :
>>>
 Thanks Filippo. I think I figured out now what was going wrong.

 I was confused between the shardId and the entityId.

 shardId == context().parent().path().name()
 entityId == self().parth().name()

 My entities were being created again and again because I was computing
 the entityId wrongly. In my case, all messages carry an id. What I need is
 entityId = hash(messageId) and shardId = hash(entityId). However, I was
 doing entityId = messageId and shardId = hash(messageId). Therefore I was
 always creating a new entity because the messageId is unique. I've fixed my
 MessageExtractor now and everything goes as it should.

 thanks,

 Bert


 On Thursday, February 11, 2016 at 5:36:17 PM UTC+1, Bert Robben wrote:
>
> Hi,
>
> I'm trying to use sharding and that works reasonably well (my entities
> are being created across my cluster and they respond to my requests).
>
> However, I notice that after each call to my entity, it is destroyed.
> Every next call on the entity then recreates it. This is not ideal for me
> since restarting my entity is a heavy process (I might need to recover 
> lots
> of state from the database). So I would like to tune the system such that
> my entities are survive for much longer (they are perfectly suited to
> handle many concurrent requests). Is this somehow possible with the 
> current
> implementation?
>
> Note that I use state-store-mode = ddata and I don't make use of Akka
> Persistence.
>
>
> Also, in my case it is vital for my entity to know its id, because
> that's how it discerns itself from the other entities. The only way I've
> found to get to the id now is to do context().parent().path().name(). That
> works, but feels very implementation dependent. Am I missing some easier
> API?
>
>
> thanks,
>
> Bert
>
 --
 >> 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.

>>> --
>>> >> 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 a topic in the
>>> Google Groups "Akka User List" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/akka-user/njCIQqOJTrw/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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.
>>>
>>
>> --
>> >> 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
>> ---

Re: [akka-user] Re: Akka persistence query examples

[Andrew Easter]

Hi Patrik. Thanks for this. I reckon I get it now :-)

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

Re: [akka-user] Re: Using local file system to store Actor's state ?

[Michael Frank]

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/
>> 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.


--

 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.

Re: [akka-user] Remoting transport back-pressure

[Michael Frank]

i think you will need to implement your own acking protocol.

SourceActor sends something like PushMessage to ProcessingActor, which 
enriches the message with some processing, then sends to the remote 
CollectingActor.  CollectingActor then responds to ProcessingActor with 
AckMessage.  ProcessingActor forwards the AckMessage to SourceActor.  
Once SourceActor receives AckMessage it sends the next PushMessage.


I don't think bounded mailboxes are a good solution, because they have a 
fixed capacity, and that capacity is not related to your network 
capacity.  an acking protocol will get you better network utilization, 
and be more tolerant/performant with respect to changing network conditions.


-Michael

On 02/10/16 17:37, Luben Karavelov wrote:

Hi,

I have the following push dataflow using remote actors (netty.tcp 
transport) over the network:


SourceActor -> ProcessingActor ~~ network ~~> CollectingActor

The problem is that if the network is relatively slow the processing 
actor successfully sends the messages but they get all buffered inside 
the same JVM until it blows with OOM. I am looking how to slow down 
the SourceActor if the upstream network is slower than the production 
rate. I have put bounded mailbox between the Source and Processing 
actor but it does not help because the ProcessingActor is not slowed 
by the network transport.


I looked at the code and it looks the problem arises because the 
EndpointWriter actor (that is kind of a proxy between the local actors 
and the transport as far as I understand) buffers the data to be sent 
in itself.


So here are my questions:

1. Is there a way to create a back-pressure between the network 
transport and the sender?


2. If there is no way and I have to create an application level 
flow-control over the network (between the Processing and Collecting 
actors) what will be the best way to slow down the SourceActor? Should 
I extend the flow control down to it? Or is there a way to slow down 
the reception of messages coming from the SourceActor so that the 
bounded mailbox will slow it down (I will still need the other 
messages to be delivered for flow-control signalization)?


Thanks in advance for any advises and suggestions,
luben



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


--

 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.