Just one addition to that: have you chosen a better-than-default
serializer? I generally agree with the principle of "no premature
optimization", but this *is* a common newbie problem, and might make a
major difference in the case you're describing.
That is, it's generally agreed that the lowest-common-denominator built-in
Java Serializer is just about the worst option in most cases. That doesn't
matter too much in many non-persistence cases (I'm only addressing it now
myself, since I haven't had enough traffic to care), but it can reportedly
make a major difference if you're sending huge numbers of messages across
the wire...
On Wed, Jun 8, 2016 at 1:02 PM, kraythe <kray...@gmail.com> wrote:
> Fair comment. :)
>
>
> On Wednesday, June 8, 2016 at 11:25:22 AM UTC-5, Ryan Tanner wrote:
>>
>> Unless you've profiled and found it to be a problem, worry about it later.
>>
>> On Wednesday, June 8, 2016 at 10:10:37 AM UTC-6, kraythe wrote:
>>>
>>> Sorry but i have another newbie question. I have an actor that uses
>>> cluster sharding. There are potentially millions of these in the sytem
>>> concurrently and they maintain some state. At some point I would like to
>>> contact a million of these and ask them for their state to render
>>> information or apply analytics on the states. I could easily do something
>>> like this:
>>>
>>> private void collectData(final Set<Integer> ids) {
>>> final ActorRef ref =
>>> ClusterSharding.get(MyApp.getActorSystem()).shardRegion(MyActor.SHARD_REGION);
>>> ids.stream().forEach(ref.tell(new MyActor().GetState(id)));
>>> }
>>>
>>>
>>>
>>>
>>> The problem i see is that we are running 9 nodes nominally (there can be
>>> nodes rolling and other cluster issues) and if I do this call, Im almost
>>> guaranteed that I am creating a million messages and sending 8/9 ths of
>>> them over serialization to another node. I keep thinking there has to be a
>>> better way to call a whole series of actors designated by ids but with the
>>> SAME message and have the sharding system do its magic, creating actors as
>>> needed if they have been passivated and sending the message to them. It
>>> would be even better if I could provide a list of IDs and the rest of the
>>> message would be packaged up.
>>>
>>> Or it could be that I am overthinking this and should just flood the
>>> system. After this initial pull the analytics system gets updates from
>>> those actors via Distributed PubSub and that is efficient, its just at this
>>> initial call that it MIGHT be bad. For some sets of data the numbers of
>>> actors i am talking to only number in the tens but for other sets they
>>> number in the millions.
>>>
>>>
>>>
>>>
>>> --
> >>>>>>>>>> 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.
