Hi Patrik,

Making "remembered" an explicit choice forces people to think about it. 
It's a good start. In the future this needs a solution, as sharding is 
typically used in situations where the solution does not fit on one 
machine. When someone reaches that point without a solution, it will be a 
big problem. A first solution that comes to mind is using a lower bound 
number of nodes to be "up" in the cluster to eagerly startup. This makes it 
possible to restart your complete solutions when the "active" entities no 
longer fit on one machine.

Do you (or anybody else) now of any solutions that are used with other 
sharding technology? Do they read into memory? The point with Akka is that 
actors are "living" things and can have behaviour in time. So they need to 
be active in memory. Probably something other sharding technologies do not 
have to deal with and where balancing data is more important than 
behaviour. 

Cheers,
Jeroen


Op donderdag 21 augustus 2014 10:25:14 UTC+2 schreef Patrik Nordwall:
>
> Hi Jeroen,
>
> This is an excellent question and it might need a solution, but first of 
> all, making entries "remembered" and eagerly started is something you have 
> to specify per entry type. Not all entries are remembered by default. It is 
> intended for those entries that need this, i.e. those that are active 
> without input from external messages.
>
> Cheers,
> Patrik
>
>
>
> On Wed, Aug 20, 2014 at 10:39 PM, Jeroen Gordijn <[email protected] 
> <javascript:>> wrote:
>
>> Hi,
>>
>> I saw this tweet by Patrik: 'Fantastic #Akka 
>> <https://twitter.com/hashtag/Akka?src=hash> contribution by Dominic 
>> Black merged to master. Cluster sharding remembers active entries. 
>> https://github.com/akka/akka/pull/15597 … <https://t.co/P32NbQQokG>' I 
>> think it is a really cool feature to be able to reactivate active entities 
>> in a cluster when rebalancing occurs. So thanks to Dominic for the great 
>> work! I will benefit a lot from this feature. However I am wondering about 
>> fault tolerance.
>>
>> One would typically use sharding when the actors doesn't fit on one 
>> machine (CPU or Memory) right? So restarting the sharded entries eagerly 
>> could end up in a software solution that will be unable to restart again, 
>> or will tear down the whole cluster when rebalancing. I guess we need some 
>> strategy to prevent this eager restarting when there are not enough (how do 
>> we now what is enough) nodes in the cluster. This will keep the cluster 
>> alive. How do the NoSQL Databases that support sharding do this? 
>>
>> Is there already a strategy to prevent eager restarting to make this 
>> feature fault tolerant?
>>
>> Cheers,
>> Jeroen
>>
>> -- 
>> >>>>>>>>>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe <http://typesafe.com/> -  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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to