Re: [akka-user] akka cluster connection refused

[Martynas Mickevičius]

You have seed-nodes setting pointing to other node in the cluster. So
naturally when you first start either node it tries to connect to the other
one which has not been started yet. Thus the log message: Reason:
Connection refused: /10.xxx.xxx.xxx:15672

You can choose which node you want to start first and have its own address
in the seed-node list. This way the first node will start the cluster with
itself.

Then when you start the second node, it will try to connect to the first
one and will successfully join the cluster.


On Wed, May 28, 2014 at 6:03 PM, Johan Dindaine wrote:

> Hi,
>
> I'm trying to connect two nodes together using akka-cluster and even if I
> thought they were setup correctly, while trying to launch the application I
> ran into connection problems.
>
> [info] [WARN] [05/28/2014 16:50:09.017]
> [ClusterSystem-akka.remote.default-remote-dispatcher-66] [Remoting] Tried
> to associate with unreachable remote address
> [akka.tcp://clustersys...@10.xxx.xxx.xxx:15672].  Address is now gated
> for 5000 ms, all messages to this address will be delivered to dead
> letters. Reason: Connection refused: /10.xxx.xxx.xxx:15672
>
> I have got two nodes and they are configured to talk to each other despite
> the connection problem:
>
> On node A:
>
> akka {
>
>   actor {
>
> provider = "akka.cluster.ClusterActorRefProvider"
>
>   }
>
>   remote {
>
> [*]
>
> netty.tcp {
>
>   hostname = "10.yyy.yyy.yyy"
>
>   port = 15699
>
> }
>
>   }
>
>
>   cluster {
>
> seed-nodes = ["akka.tcp://clustersys...@10.xxx.xxx.xxx:15672"]
>
>   }
>
> }
>
>
> And on node B
>
> akka {
>
>   actor {
>
> provider = "akka.cluster.ClusterActorRefProvider"
>
>   }
>
>   remote {
>
> [*]
>
> netty.tcp {
>
>   hostname = "10.xxx.xxx.xxx"
>
>   port = 15672
>
> }
>
>   }
>
>
>   cluster {
>
> seed-nodes = ["akka.tcp://clustersys...@10.yyy.yyy.yyy: 15699"]
>
>   }
>
> }
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] supervisor hierarchies

[Jabbar Azam]

Hello Konrad,

I had read the relevant documentation but I still couldn't work out the 
structure of the actor hierarchies.  Does this mean that there you should 
only have one actor which is the child of the user guardian, or am I 
missing something?

On Wednesday, 28 May 2014 23:24:08 UTC+1, Konrad Malawski wrote:
>
> Hello Jabbar,
> In general try to prefer creating deeper hierarchies instead of flat ones.
> I like to demonstrate this on a bit more finer granularity than in the 
> above example: let's say your actor represents a piece of work (maybe a web 
> request), and it's coordinating some work, which it's children execute. 
> When one dies (let's say the DB underneath it has died) you can then 
> *there* decide how to handle this - by for example killing all other 
> actors, since you won't be able to compute the end-result anyway with this 
> one guy dead.
>
> I assume you have read through the examples on fault 
> tolerancefrom 
> the docs already.
> I think that the diagrams for the fault 
> toleranceexample
>  are esp. helpful to see how this all fits together - it highlights 
> an recovery / auto-healing scenario.
>
> I hope this helps, cheers!
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker - Typesafe, Inc
>
> 
>  

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unable to test `Processor` and `EventsourcedProcessor` with `CallingThreadDispatcher`

[Lawrence Wagerfield]

I may have answered my own question: Scala Mixins!

trait ChecksEmailAddressAvailability extends Actor {
  val emailCredentialsView: ActorRef
  
  protected def checkEmailAddressAvailability(emailAddress: 
EmailAddress)(block: Boolean => Unit)(implicit context: ActorContext): Unit 
= {
queryAvailabilityOf(emailAddress)
yieldResultTo(block)
  }

  private def queryAvailabilityOf(emailAddress: EmailAddress): Unit =
emailCredentialsView ! EmailAddressAvailabilityQueried(emailAddress)

  private def yieldResultTo(block: Boolean => Unit)(implicit context: 
ActorContext): Unit =
context become {
  case EmailAddressAvailabilityDetermined(emailAddressAvailable) =>
context unbecome()
block(emailAddressAvailable)
}
}


class EmailCredentialRegistrationCommand extends EventsourcedProcessor with 
ChecksEmailAddressAvailability 
{
   ...
   checkEmailAddressAvailability(emailAddress) { isAvailable =>
   ...
   }
   ...
}

If I am not mistaken, this pattern seems consistent with how parts of Akka 
are implemented.

What do you think?


On Thursday, May 29, 2014 7:41:03 AM UTC+1, Lawrence Wagerfield wrote:
>
> Hi Roland,
>
> Yes that makes sense, especially since the class is effectively an actor :)
>
> Does the same rule apply with code that just performs some behaviour on 
> behalf of an actor? I.e. code that doesn't actually represent an actor in 
> its own right?
>
> In my example, I have isolated the 'chatter' involved in determining email 
> address availability into its own type:
>
> trait EmailAddressAvailabilityQuery {
>   def apply(emailAddress: EmailAddress)(consumer: Boolean => 
> Unit)(implicit context: ActorContext): Unit
> }
>
> class EmailAddressAvailabilityQueryImpl(emailCredentialsView: ActorRef) 
> extends EmailAddressAvailabilityQuery {
>   override def apply(emailAddress: EmailAddress)(consumer: Boolean => 
> Unit)(implicit context: ActorContext): Unit = {
> queryAvailabilityOf(emailAddress)
> yieldResultTo(consumer)
>   }
>
>   private def queryAvailabilityOf(emailAddress: EmailAddress): Unit =
> emailCredentialsView ! EmailAddressAvailabilityQueried(emailAddress)
>
>   private def yieldResultTo(consumer: Boolean => Unit)(implicit context: 
> ActorContext): Unit =
> context become {
>   case EmailAddressAvailabilityDetermined(emailAddressAvailable) =>
> context unbecome()
> consumer(emailAddressAvailable)
> }
> }
>
> This produces a very nice level of abstraction for the calling code (which 
> is within an actor). It also isolates all the message type details to one 
> place, making the code much more maintainable if I were to ever change 
> email address availability lookup.
>
> emailAddressAvailabilityQuery(emailAddress) { emailAddressAvailable =>
> if (emailAddressAvailable)
>   allowRegistration()
> else
>   denyRegistration()
> }
>
> Do you suggest that I inline the implementation of the 
> EmailAddressAvailabilityQueryImpl and remove the class?
>
> Thanks,
> Lawrence 
>
>
> On Thursday, May 29, 2014 7:18:08 AM UTC+1, rkuhn wrote:
>>
>> Hi Lawrence,
>>
>> you don’t need to pass around ActorContext: just return the Props to the 
>> actor and call context.actorOf() there. Passing around ActorContext is not 
>> something that should be handled with caution, it is a recipe for disaster 
>> and will result in weird failures eventually; the reason is that because of 
>> the Actor Model you or your team will think that low-level synchronization 
>> is not an issue, and keeping only exactly this one type separate is tedious 
>> and error-prone.
>>
>> When it comes to testing I recommend functional tests only (message in, 
>> message(s) out), no verification of meaningless details such as passing an 
>> implementation detail to some mock—that will only break once you improve 
>> your implementation and thereby create extra work and impede progress. In 
>> the case at hand you would give a Props-factory to your Actor (the 
>> FulfilRegistration class with my suggested modification) and during test 
>> you can have that inject the right stub actors quite naturally.
>>
>> Regards,
>>
>> Roland
>>
>> 28 maj 2014 kl. 18:00 skrev Lawrence Wagerfield <
>> lawr...@dmz.wagerfield.com>:
>>
>> I had an Actor whose code grew to be quite large, so this is the result 
>> of a refactoring.
>>
>> The new class performs actions on behalf of the actor, impersonating it, 
>> so to speak. It caries out various send operations, sets up state with 
>> un/become, etc.
>>
>> The refactor produces clearer and more testable code, although I do 
>> appreciate why ActorContext (or any other internal state) should be handled 
>> with caution.
>>
>> My code is as follows:
>> *(note: CheckEmailAddressAvailability follows a similar pattern - code 
>> omitted as you'll already get the idea!)*
>>
>> class UserRegistry(fulfilRegistration: FulfilRegistration) extends 
>> EventsourcedProcessor {
>>   override def receiveRecover: Receive = {

Re: [akka-user] supervisor hierarchies

[Konrad Malawski]

Not "exactly one", but yeah "as little as possible".
This way of thinking will force your thinking towards creating these
hierarchies of actors which fail or survive together (kind of like the four
musketeers :-)).
And the gains have been outlined already - you are able to fail / restart /
isolate failures within one such hierarchy.


-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker - Typesafe, Inc



-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Unable to test `Processor` and `EventsourcedProcessor` with `CallingThreadDispatcher`

[Lawrence Wagerfield]

Ah yes, I had forgot to remove that!

Good suggestion on using self-typing to abstract-away implementation detail 
:D

The code is looking a lot better now guys, and there's no funny business! 
Thanks!

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] supervisor hierarchies

[Jabbar Azam]

Thanks Conrad I understand.

I think understanding the "error kernel pattern" is really important 
together with http://doc.akka.io/docs/akka/2.3.3/general/actor-systems.html 
of the documentation. 


On Thursday, 29 May 2014 11:48:28 UTC+1, Konrad Malawski wrote:
>
> Not "exactly one", but yeah "as little as possible".
> This way of thinking will force your thinking towards creating these 
> hierarchies of actors which fail or survive together (kind of like the four 
> musketeers :-)).
> And the gains have been outlined already - you are able to fail / restart 
> / isolate failures within one such hierarchy.
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker - Typesafe, Inc
>
> 
>  

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is ask an anti-pattern in akka actors?

[Filippo De Luca]

Thanks it makes perfectly sense, it was my feeling.
On May 28, 2014 4:28 PM, "Heiko Seeberger" 
wrote:

> Actor selection essentially is look up and we all know that look up should
> not be overused. It has it’s purpose though, e.g. when you want to connect
> to a remote system (How would you get an actor ref for a remote actor?).
> Rule of thumb: If you have an actor ref, use it.
>
> Heiko
>
> On 28 May 2014, at 16:31, Filippo De Luca  wrote:
>
> ​Hi Heiko,
> So moving forward, is the actor selection a bad practice instead? The
> temptation to don't pass the actorRef and instead let the actor search for
> the dependencies is high, but I see difficulties to test and and heavy
> dependency on the actor system hierarchy.​
>
> Any thoughts on that? Thanks.
>
> On 28 May 2014 14:41, Heiko Seeberger  wrote:
>
>> Then your problem is not related to the ask pattern, but using
>> `ActorSelection` instead of `ActorRef`.
>
>
>
>
>
> --
> *Filippo De Luca*
> -
> WWW: http://filippodeluca.com
> IM:  filosgang...@gmail.com
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> Heiko Seeberger
> Twitter: @hseeberger
> Blog: blog.heikoseeberger.name
>
>
>
>
>  --
> >> 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 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to Store the Message Object/Class to a database?

[Konrad Malawski]

Hello Allen,
have you had the chance to look into our akka-persistence
 module?
Apps like you describe are very nicely modelled as events and “opposite
events” if you want to “undo”.

And direct answers to your questions:

   - path - the actor knows its full path via self.path ( see:
   http://doc.akka.io/api/akka/2.3.3/#akka.actor.ActorPath )
   - storage - well, the entire interwebs somehow store objects in
   databases :-) One way to go around this is some object to relational /
   document mapper. But in Akka’s case I would recommend using akka-peristence
   :-)

I hope this helps!
​
-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker - Typesafe, Inc



-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AOP in Akka

[Konrad Malawski]

Hello Leon,
Well, "the Scala way"™ would rather be using plain total or partial
functions and composing them - I believe that's what whoever the quoted
sentence comes from had in mind.
In Akka we also believe that less magic is better :-)

I would therefore suggest you to try modelling your required behaviour in
terms of functions instead of aspects.
What's your use case?


-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker - Typesafe, Inc



-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to Store the Message Object/Class to a database?

[Allen Nie]

Wow! I didn't know akka-persistence. Thank you Konrad! Akka is very very 
powerful.

On Thursday, May 29, 2014 11:22:21 AM UTC-4, Konrad Malawski wrote:
>
> Hello Allen,
> have you had the chance to look into our 
> akka-persistencemodule?
> Apps like you describe are very nicely modelled as events and “opposite 
> events” if you want to “undo”. 
>
> And direct answers to your questions: 
>
>- path - the actor knows its full path via self.path ( see: 
>http://doc.akka.io/api/akka/2.3.3/#akka.actor.ActorPath ) 
>- storage - well, the entire interwebs somehow store objects in 
>databases :-) One way to go around this is some object to relational / 
>document mapper. But in Akka’s case I would recommend using 
> akka-peristence 
>:-) 
>
> I hope this helps!
> ​
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker - Typesafe, Inc
>
> 
>  

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to Store the Message Object/Class to a database?

[Konrad 'ktoso' Malawski]

Glad I could help! Happy hakking!
-- 
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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] [streaming] newbie Q's about time and scale

[Ian Holsman]

Hi.
I'm recently read about reactive streams, and want to know some more about
it.

In particular I was trying to use the 'Flow' methodology to replace some
existing log-analysis software, which does things like page views, unique
visitors and things like that in 5 minute blocks. It looks quite simple to
create the flows, and the 'esper' example I found looks really close.

but I have two questions.

how does one deal with time. specifically how do I set up a periodic
scheduler to tell the flow that it's time to emit results. (and ideally
allow my service to set the time based on input records and not use system
time, so I can do stuff like replaying logs)

and secondly how do I scale these flows to work over multiple machines.
Ideally I'd like to just hand a dozen machines to Akka and say 'go wild'
and let it figure it all out, but failing that how can I allocate resources
to a producer?

Thanks
Ian



-- 
Ian Holsman
i...@holsman.com.au
PH: + 61-3-9028 8133 / +1-(425) 998-7083

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.