Hi David and welcome to Scala/Akka!
Your design looks pretty OK :-)
I'll comment on a few things and you questions in-line, below:
class MyDBClient extends Actor{
> val client = Client( "102.98.2.1:3000" )
>
> def receive = {
> case ReadCommand( id ) =>
> val orig_sender = sender
> val f:Future[Option[String]] = client.get( id )
> f pipeTo orig_sender
> case _ =>
> }
> }
>
> No need to freeze the sender to orig_sender here, because you're not in a
future but using pipeTo instead - which is safe from the usual sender
problems (closing over it in a Future).
On the other hand, if you like this pattern for safety - harder to miss
freezing a value if you do it everywhere then cool, sounds like a plan as
well :-)
class DBManager extends Actor{
>
> [...] looks OK. You could put the router in a `val` instead.
class ConfirmationCalc( dbClient:ActorRef ) extends Actor{
>
> def receive:Receive = {
> case CalculateFor( id ) =>
> val orig_sender = sender
> val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
> f.onComplete{
> case Success( result ) => result match {
> case Some( click ) =>
> println( "Success: calculate using {}", click )
> orig_sender ! calculate( click )
>
> // hint: good, here freezing the sender was needed.
> 1. Is this the "correct" pooling architecture - that is, having a central
> router that delegates to a number of dbactors which have a "connection" to
> the database? Are there other architectures given that each DB Client class
> controls its own connections?
>
> What you designed here is OK.
If this is a blocking database driver the bigger problem is blocking the
actor's threads when performing the query - you should then configure
dedicated dispatchers for the blocking code.
But since you said your db client returns a future and has some threadpools
of it's own I guess this shouldn't be a problem here (make sure it has a
dedicated thread pool, not the same one as the rest of the actor system).
> 2. ConfirmationCalc actor will be furiously processing "CalculateFor"
> messages. I understand that the future will eventually complete with either
> Success or Failure or timeout.
>
> Correct, and timeout is a Failure, so you'd handle it in the onComplete.
> [...] I would be getting the *first message's db results* *when processing
> the second message* and send back the *first results to the sender who is
> expecting the second results*. [...]
>
> It's true that this problem shows up when combining futures and
`sender()`. In your code however you have already guarded against that -
the way you "freeze" the sender value saves you
from the described concurrency problem. So while sender() may be "the
second guy" when the onComplete of "first" triggers, you're not using
sender() but orig_sender - which is a value frozen with the original sender
("first sender"). So all's good here.
3. This is related to my previous question. In asynchronous systems,
we might have ActorA asking ActorB asking ActorC asking ActorD. I
find it a bit mind bending how each actor in the chain is going to
maintain state of futures. Future A may have onCompletions triggered
thousands of times while it is processing a message. Is there example
code somewhere that addresses this?
>
> I'm not sure what exactly you're asking about here. Do you want to know
when futures trigger?
Maybe this may clarify – instead of thinking "the actor's oncomplete may
trigger", think "ok, so i have given this future a function that *IT* will
trigger when it gets completed",
it doesnt really have much to do with the actor other than that it may
share the same threadpool. So when you give stuff to a future to execute,
it becomes it's job to trigger these things (using whatever
execution context was used for the Future - in actors we often use import
context.dispatcher - so it's the same threadpool, not neccessarily not the
same thread).
Hope this helps!
--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe
--
>>>>>>>>>> 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.
