Hi Guido, mine is a similar use case. One difference is that I store the
actorrefs to files on disk as I am expecting to have a lot of them and
don't want to keep them into memory. I would expect to say have 1000
servers with 1000 actorrefs per server for 1 "index" of mine (index =
database index as I am building a database). This means it is costly to
do batch updates of the actor refs. So what I ended doing so far is to
serialize the actor path (after injecting the real server RootAddress to
it). Then I resolveOne actorRef and I keep that ref into memory for 10
seconds and then resolveOne again. This means that my servers don't have
to communicate up/down and it works if servers crash/restarts too. The
whole trick is achived by replacing ActorRef with EndpointActorRef (a
class of mine) which does the actorPath manipulation and takes care of
serializing the actorPath instead of actorRef.
Overall I might end up serializing actorPath for actors in the same jvm
- if the actor is inactive for a long time. This means actors might come
and go quite frequently even if the servers are up.
What happens to your cache if a server crashes? Do the cache removes the
invalid actor refs somehow?
Cheers
On 09/11/15 23:26, Guido Medina wrote:
Hi Kostas,
I have few micro-services and some supervisor actors which inherited
from an AbstractSupervisor template which uses local caches per
microservices with an optimistic approach, example with requirements:
1) There is a uniform pattern where each micro-service is an
independent category and also each category has the capability of
being either a round-robin supervisor only or a supervisor with
children (sharding)
2) Each category informs other categories by using cluster events when
a supervisor comes up and/or any/of its children.
3) If a supervisor dies, also its children die which means that other
supervisors in other categories are informed hence the cache for that
supervisor is invalidated.
4) Each children has an Integer ID, say, category account and account
1, 2, ...., 10 so I don't bother giving a path to children, I know a
children of account is ../acccount/$blah blah incarnation, so what I
do to inform caches of other microservices that Account ID X = ActorRef Y
All this would suggest that cluster sharding is what I use but no, it
is very similar but I have my own implementation constrained more to a
DDD.
I probably confused you more than what I helped you, all I wanted to
say is that caching a key with a corresponding ActorRef is not a bad
idea, of course if one of your microservices goes down you need to
invalidate caches in order to avoid actor selection calls which I
would discourage you to do, instead (but not free since I had to put
lot of work on contemplating different scenarios), do an inventory of
your events and try to react on them.
I particularly designed the application to build the caches using
cluster events and template pattern (preStart and postStop for some
type of actors would inform other caches)
Having also an uniform hierarchy will help like supervisor -> children
so that you can add or invalidate a whole branch (I do that too with
my mini-framework)
Hope all these crazy ideas can help you.
Best regards,
Guido.
On Friday, November 6, 2015 at 4:15:24 PM UTC, Kostas kougios wrote:
Well, I refactored my code to cache actorpaths but indeed during
creation all actorpaths are local and when they are transmitted
over the wire they remain local => pointing to the wrong path.
I've manually modified the address part of the path myself so that
it contains the host & port of the server. But the process seems
awkward , am I missing something?
--
>>>>>>>>>> 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/n8HlIIkZhCs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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.
