*Incomplete sentence:* My seed nodes are the active-passive coordinator 
role., the 1st one that comes up acts as master distributor for shard IDs 
of each role, each role type has a custom SQL of what filters it needs, 
example SupervisorType class:
*Integers class:* https://gist.github.com/guidomedina/b586936a4625ae3a25ca

On Friday, February 26, 2016 at 2:27:21 PM UTC, Guido Medina wrote:
>
> Take into account the distinction between outside world (HTTP, Websockets) 
> and inside world (Akka Cluster with each role with some HA capability)
>
> *Disclaimer:* I have only 1 year of experience using Akka but 
> successfully implemented my shard for DDD:
>
> I have HTTP servers load balanced with HA proxy but for Akka I prefer the 
> cluster to take of it by balancing roles with different types of 
> distribution which are:
>
>    - *Round-robin:* A stateless role on the cluster, host as many as you 
>    want and a local round-robin router of this role is created at each other 
>    role node.
>    - *Active-Passive:* A singleton role, can be only one in the cluster, 
>    for example my shard coordinator is of this type, if this node dies next 
>    node take over and notifies the cluster.
>    - *Shard:* Using the coordinator role it tells each node of each role 
>    which IDs it should load, I use for this a data structure of my own that 
>    compresses the ranges, for example, if you need to load ID 1,2,3,4,8,10 
> you 
>    will get the ranges: [1,4],[8],[10], this is good for IDs that were 
>    generated by a sequence, so each node will have even (as much as possible) 
>    amount of domain objects for that role (My seed nodes are ), I can Gist my 
>    ranges class if anyone wants it, it uses binary search to insert/remove 
>    elements, similar to Guava's range but simpler.
>
> I have one supervisor actor per node which is subscribed to cluster events 
> so each supervisor reacts upon MemberUp and MemberDown events, this is key 
> to my design.
>
> So in this particular case the cluster takes care of itself, I don't like 
> the idea of HA proxy within the cluster but only to the outside world as 
> Gossip protocol takes care of the Cluster state though this need 
> improvement which I think is the purpose of ConductR.
>
> Anyway, hope this generic idea helps,
>
> Guido.
>
> On Sunday, February 21, 2016 at 2:49:30 PM UTC, Paul Cleary wrote:
>>
>> I use HA PROXY and have blue / green (active + dark) backends.  This 
>> allows us to do a seamless traffic shift during an upgrade.  It also allows 
>> you to test the upgrade prior to making it "live".
>>
>> For the app, it depends on what you want to do.
>>
>> If you are using DDD, CQRS and model domains, then a typical approach is 
>> to model your Aggregate Roots such that they leverage Akka Clustering. 
>>  This way, only one instance of a particular entity is active in the 
>> cluster at any time.
>>
>> Akka Clustering takes care of failing over the entities to other nodes in 
>> case one crashes (look at remember-entities if you want the entity to auto 
>> start).
>>
>> If your application is purely stateless (you don't need the above), then 
>> hell, just slap HA PROXY in front and round robin, you will be in a nice 
>> place.
>>
>> On Thursday, February 18, 2016 at 6:41:06 AM UTC-5, Chelios wrote:
>>>
>>> Hey Guys,
>>>
>>> What is recommended way of scaling Akka application? 
>>>
>>> Traditionally to scale a CRUD based 3 tiered application (Controller, 
>>> Services, DAO) I would simply create copies of the application and slap a 
>>> load balancer behind my applications to distribute the load.  
>>>
>>> I know I should use remote actors and clustering to get scalability for 
>>> Akka actors. But if I had copies of my application the load balancer would 
>>> re-direct request to the second instance of my application just incase one 
>>> dies. How can I achieve the same in Akka based application if one of the 
>>> root machine where the guardian actor lives died, that would mean the whole 
>>> application (all the child actors) shuts down right because of Supervision 
>>> ? 
>>>
>>> Is it possible to spawn another guardian actor in another machine which 
>>> becomes the guardian/parent actor of the previously dead guardian actor's 
>>> children but without killing any of the child actors of the dead guardian 
>>> actor ? 
>>>
>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to