> 20 jan 2015 kl. 11:45 skrev Roland Kuhn <[email protected]>:
>
> Hi Brice,
>
>> 15 jan 2015 kl. 17:15 skrev Brice Figureau <[email protected]>:
>>
>> Hi,
>>
>> I have several utility ClusterSingleton actors in my cluster that are
>> used by several client actors (some of them are also singleton or
>> ClusterSharding entries).
>>
>> Those client actors are currently created by passing the ActoRef of said
>> utility singletons proxies as Props arguments. This can't work when
>> those actors are themselves singletons or sharded entries, because they
>> might run on a different node than the passed-in proxies (and props
>> might not even be serialized?).
>>
>> So I need to refactor all this to not pass any ActorRef.
>>
>> My question finally is what would be the best way to achieve that:
>> * have client actors create their own proxy (or ClusterShard region).
>> This doesn't seem the good solution :(
For sharded actors this a good solution, because the shard region is accessed
via the local extension anyway.
For singleton proxies you can create you own extension that holds all your
singleton proxy instances. You probably don't have a lot of singletons anyway.
If you don't have many (>20) client actors you don't need the extension for the
singleton proxies. Then each client can create its own.
/Patrik
>>
>> or
>> * have a well known per-node registry actor that creates the needed
>> proxies (and region) at start and can send those ActorRef to client
>> actors.
>>
>> I'm much more inclined toward the second solution, but unfortunately it
>> makes the various tests a bit more complex (setup a registry instead of
>> injecting TestProbe).
>
> You would still inject a TestProbe by injecting a mock registry (can be the
> same as the production code but filled with TestProbes). Otherwise I don’t
> see anything wrong with this proposal.
>
> Regards,
>
> Roland
>
>>
>> What do you think?
>> Is there a better solution I didn't think about?
>> --
>> Brice Figureau
>> My Blog: http://www.masterzen.fr/
>>
>> --
>>>>>>>>>>>> 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.
>
>
>
> Dr. Roland Kuhn
> Akka Tech Lead
> Typesafe – Reactive apps on the JVM.
> twitter: @rolandkuhn
>
>
> --
>>>>>>>>>>> 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.
--
>>>>>>>>>> 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.
