date:20151017

Re: [akka-user] Re: Behavior of Akka when you sleep in an actor

2015-10-17 Thread Konrad Malawski

On Thu, Oct 15, 2015 at 4:44 AM, Fahimeh Rahemi 
 wrote:

> Please let me see if I understand your answer correctly, do you mean that
> if I use thread.sleep(5000) inside an actor, the actor does not leave it's
> thread at all? and the thread is idle and jobless for 5 seconds?
>

Yeah, exactly. It effectively renders that thread useless for around 5
seconds – don't do that ;-)


-- 
Konrad

-- 
>>  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] No Tests to run for MultiJvm

2015-10-17 Thread Harit Himanshu

Hello everyone,

I started learning akka-cluster today and was trying to write the multi-ivm 
test.
I followed all through the document but when I run my application, I see


> ; reload ; clean ; compile ; multi-jvm:test
[info] Loading project definition from 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/project
[info] Set current project to akka-cluster-investigation (in build 
file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/)
[success] Total time: 0 s, completed Oct 17, 2015 10:08:45 PM
[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}akka-cluster-investigation...
[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}cluster_simple...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] Compiling 2 Scala sources to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/classes...
[success] Total time: 1 s, completed Oct 17, 2015 10:08:46 PM
[info] Compiling 1 Scala source to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/multi-jvm-classes...
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0
[info] No tests to run for MultiJvm
[success] Total time: 1 s, completed Oct 17, 2015 10:08:47 PM



It compiles the class but says no tests to run, My Test looks like  

import akka.remote.testkit.{MultiNodeConfig, MultiNodeSpec}
import akka.testkit.ImplicitSender
import org.scalatest.{BeforeAndAfterAll, MustMatchers, WordSpecLike}


object SimpleClusterListenerSpecConfig extends MultiNodeConfig {
  val cluster = role("cluster")
}

class SimpleClusterListenerSpec extends 
MultiNodeSpec(SimpleClusterListenerSpecConfig)
with WordSpecLike
with MustMatchers
with BeforeAndAfterAll
with ImplicitSender {

  import SimpleClusterListenerSpecConfig._

  override def initialParticipants: Int = roles.size

  "A SimpleClusterListener" must {
"wait for all nodes to enter a barrier" in {
  enterBarrier("startup")
}

runOn(cluster) {
  enterBarrier("deployed")
  val clusterSelection = system.actorSelection(node(cluster) / "user" / 
"clusterListener")
  clusterSelection ! Hello
  expectMsg("hello")
}
  }

  override def beforeAll() = multiNodeSpecBeforeAll()

  override def afterAll() = multiNodeSpecAfterAll()
}



And the entire code is available on GitHub 
. I would really 
appreciate if some one could help me spot my issue here.

Thanks
+ Harit Himanshu

-- 
>>  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] No Tests to run for MultiJvm

2015-10-17 Thread Harit Himanshu

Hello everyone,

I started learning akka-cluster today and was trying to write the multi-ivm 
test.

I followed all through the document 

 but 
when I run my application, I see



> ; reload ; clean ; compile ; multi-jvm:test

[info] Loading project definition from 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/project

[info] Set current project to akka-cluster-investigation (in build 
file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/)

[success] Total time: 0 s, completed Oct 17, 2015 10:08:45 PM

[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}akka-cluster-investigation...

[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}cluster_simple...

[info] Resolving jline#jline;2.12.1 ...

[info] Done updating.

[info] Resolving jline#jline;2.12.1 ...

[info] Done updating.

[info] Compiling 2 Scala sources to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/classes...

[success] Total time: 1 s, completed Oct 17, 2015 10:08:46 PM

[info] Compiling 1 Scala source to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/multi-jvm-classes...

[info] Passed: Total 0, Failed 0, Errors 0, Passed 0

[info] No tests to run for MultiJvm

[success] Total time: 1 s, completed Oct 17, 2015 10:08:47 PM


It compiles the class but says no tests to run, My Test looks like  

import akka.remote.testkit.{MultiNodeConfig, MultiNodeSpec}
import akka.testkit.ImplicitSender
import org.scalatest.{BeforeAndAfterAll, MustMatchers, WordSpecLike}


object SimpleClusterListenerSpecConfig extends MultiNodeConfig {
  val cluster = role("cluster")
}

class SimpleClusterListenerSpec extends 
MultiNodeSpec(SimpleClusterListenerSpecConfig)
with WordSpecLike
with MustMatchers
with BeforeAndAfterAll
with ImplicitSender {

  import SimpleClusterListenerSpecConfig._

  override def initialParticipants: Int = roles.size

  "A SimpleClusterListener" must {
"wait for all nodes to enter a barrier" in {
  enterBarrier("startup")
}

runOn(cluster) {
  enterBarrier("deployed")
  val clusterSelection = system.actorSelection(node(cluster) / "user" / 
"clusterListener")
  clusterSelection ! Hello
  expectMsg("hello")
}
  }

  override def beforeAll() = multiNodeSpecBeforeAll()

  override def afterAll() = multiNodeSpecAfterAll()
}


And the entire code is available on GitHub 
. I would really 
appreciate if some one could help me spot my issue here.

Thanks
+ Harit Himanshu

-- 
>>  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] Capturing the message that killed an actor

2015-10-17 Thread Viktor Klang

Arne,

if 2 actors have SafeReceive, send messages to eachother and they fail on
processing OperationFailed, then you have a crash loop.

What behavior are you implementing? (what are you going to use the
exception and message for?)

-- 
Cheers,
√
On 15 Oct 2015 22:44, "Arne Claassen"  wrote:

> So I came up with this workaround:
>
> object SafeReceive {
>   def apply(receive: Receive)(recover: Any => PartialFunction[Throwable,
> Unit]): Receive =
> new Receive {
>  override def isDefinedAt(x: Any): Boolean = receive.isDefinedAt(x)
>   override def apply(v1: Any): Unit = try {
>receive(v1)
>   } catch recover(v1)
> }
> }
>
> which I can invoke like this:
>
> def receive = SafeReceive {
>   
> } {
>   msg => {
> case e:Exception =>
>   sender ! OperationFailed(msg,e)
>   throw e
>   }
> }
>
> Any reason why this would be a bad idea?
>
> cheers,
> arne
>
>
> On Thursday, October 15, 2015 at 1:25:13 PM UTC-7, Arne Claassen wrote:
>>
>> Actually according to those docs, the supervisor stopping does cause the
>> message to be dropped.  The message is taken from the mailbox, causes an
>> exception and then the supervisor stops the actor, never returning the
>> message to the mailbox. I've tested to verify that that is the behavior.
>>
>> What confuses me is the following:
>>
>>> *It is important to understand that it is not put back on the mailbox.
>>> So if you want to retry processing of a message, you need to deal with it
>>> yourself by catching the exception and retry your flow.*
>>
>>
>> I.e. I would need to wrap every pattern match or at least every Receive
>> definition in a try/catch to get at the message.I thought the whole point
>> of the Let It crash philosophy is that I don't need to wrap everything i do
>> in a try catch to guard against bugs, since the actor crashing handles that
>> behavior.
>>
>> cheers,
>> arne
>>
>> On Thursday, October 15, 2015 at 12:40:34 PM UTC-7, Ryan Tanner wrote:
>>>
>>> Actors aren't necessarily stopped due to user-land messages.  If you use
>>> context.stop(ref), what would be the message in postStop?  Though I suppose
>>> it could be an Option.
>>>
>>> That said, to answer your question, it is definitely intentional.
>>>
>>> If an exception is thrown while a message is being processed (i.e. taken
 out of its mailbox and handed over to the current behavior), then this
 message will be lost.

>>>
>>>
>>> http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#What_happens_to_the_Message
>>>
>>> If the supervisor strategy governing that failure stops the actor
>>> without restarting it, then yes the messages in the mailbox will go to
>>> DeadLetters.  If the actor is restarted after failure, the mailbox will be
>>> unaffected and the new incarnation of the actor will pick up where the dead
>>> actor left off (minus the actor that caused the failure).
>>>
>>> On Thursday, October 15, 2015 at 12:31:39 PM UTC-6, Arne Claassen wrote:

 The scenario in which this came up was one of a bug causing the death.
 I.e. it wasn't perceived to be a dangerous operation, I wanted a way to
 quickly deal with the failure rather than having the sender rely on a
 timeout.

 Clearly it was considered desirable to recover the cause, since
 preRestart gets the message. Shouldn't it be even more desirable to get the
 cause (if even just for logging) in the case that the actor is actually
 stopped?

 I guess the real question is, is it intentional that in the case of
 stopping an actor the message that caused the error is silently dropped
 while anything still in the mailbox goes to dead letters?

 thanks,
 arne

 On Thursday, October 15, 2015 at 11:07:17 AM UTC-7, √ wrote:
>
> If the actor is doing something dangerous then its parent should have
> delegated that dangerous work to it so it should know what that message 
> is.
> I.e. create a temporary actor to deal with the dangerous message and then
> it can send a message to sender in postStop?
>
> On Thu, Oct 15, 2015 at 7:38 PM, Arne Claassen 
> wrote:
>
>> I'm trying to respond to the sender of a message that killed my
>> actor. I know I get the message if in preRestart if I chose to restart, 
>> but
>> if my supervisorStrategy decided to stop (because of max retries or some
>> other reason), there doesn't seem to be any way to get at the message. 
>> The
>> actor itself just receives the postStop() and the supervisor only 
>> receives
>> the Throwable. I even looked in DeadLetters, but it only gets subsequent
>> messages sent to the dead ActorRef, not the message that caused the 
>> death.
>>
>>
>> Am I overlooking some other mechanism for getting at this message?
>>
>>
>> thanks,
>>
>> arne
>>
>> --
>> >> Read the docs: http://akka.io/docs/

[akka-user] Fwd: Proposed major simplification of the Akka Streams FlowGraph APIs

2015-10-17 Thread Viktor Klang

Hi everyone,

I'm proposing the following (breaking) changes to the FlowGraph-related
APIs, in order to make it consistent, with a smaller surface area and with
more obvious demarcation of power-level for "dropping down to"/"tapping
into" FlowGraph-mode.

Most, if not all, of the migration can be mechanically applied (I know
because I did it in the codebase).

See the PR for details: https://github.com/akka/akka/pull/18700

-- 
Cheers,
√

-- 
>>  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] Capturing the message that killed an actor

2015-10-17 Thread Arne Claassen

Viktor,

Yeah, i can see a crash loop being undesirable, but it shouldn't be a 
problem in my scenario, since only one end is really an actor.

The scenario is the following:
1. HTTP request comes into play for some analytics for a specific resource
2. The request gets routed to a persistent actor on an akka cluster
3. The resource actor may return a previously calculated result or 
calculate one
4. Since the calculation may take some time, my ask has a longish timeout
5. If the actor fails in its operation due to some scenario that wasn't 
considered as a possible failure scenario, I want to notify the waiting 
HTTP call as soon as possible, rather than have the call time out
6. The HTTP request gets completed with either the 200 analytics response 
or a 500, trying to use 408 only for actual timeouts not failures in the 
message flow

Ideally, the communication channel between the HTTP endpoint and the 
resource would be a protocol more resilient than a single ask, such as 
having an initial ack, and some heartbeat, but for now it's just that ask 
and I'm trying to communicate failure back to the caller in the most timely 
fashion.

thanks,
arne

On Saturday, October 17, 2015 at 5:01:52 AM UTC-7, √ wrote:
>
> Arne,
>
> if 2 actors have SafeReceive, send messages to eachother and they fail on 
> processing OperationFailed, then you have a crash loop.
>
> What behavior are you implementing? (what are you going to use the 
> exception and message for?)
>
> -- 
> Cheers,
> √
> On 15 Oct 2015 22:44, "Arne Claassen"  
> wrote:
>
>> So I came up with this workaround:
>>
>> object SafeReceive {  
>>   def apply(receive: Receive)(recover: Any => PartialFunction[Throwable, 
>> Unit]): Receive = 
>> new Receive {
>>  override def isDefinedAt(x: Any): Boolean = receive.isDefinedAt(x) 
>>   override def apply(v1: Any): Unit = try {
>>receive(v1) 
>>   } catch recover(v1)  
>> }
>> } 
>>
>> which I can invoke like this:
>>
>> def receive = SafeReceive {
>>   
>> } {
>>   msg => {
>> case e:Exception =>
>>   sender ! OperationFailed(msg,e)
>>   throw e
>>   }
>> }
>>
>> Any reason why this would be a bad idea?
>>
>> cheers,
>> arne
>>
>>
>> On Thursday, October 15, 2015 at 1:25:13 PM UTC-7, Arne Claassen wrote:
>>>
>>> Actually according to those docs, the supervisor stopping does cause the 
>>> message to be dropped.  The message is taken from the mailbox, causes an 
>>> exception and then the supervisor stops the actor, never returning the 
>>> message to the mailbox. I've tested to verify that that is the behavior. 
>>>
>>> What confuses me is the following:
>>>
 *It is important to understand that it is not put back on the mailbox. 
 So if you want to retry processing of a message, you need to deal with it 
 yourself by catching the exception and retry your flow.*
>>>
>>>  
>>> I.e. I would need to wrap every pattern match or at least every Receive 
>>> definition in a try/catch to get at the message.I thought the whole point 
>>> of the Let It crash philosophy is that I don't need to wrap everything i do 
>>> in a try catch to guard against bugs, since the actor crashing handles that 
>>> behavior.
>>>
>>> cheers,
>>> arne
>>>
>>> On Thursday, October 15, 2015 at 12:40:34 PM UTC-7, Ryan Tanner wrote:

 Actors aren't necessarily stopped due to user-land messages.  If you 
 use context.stop(ref), what would be the message in postStop?  Though I 
 suppose it could be an Option.

 That said, to answer your question, it is definitely intentional.  

 If an exception is thrown while a message is being processed (i.e. 
> taken out of its mailbox and handed over to the current behavior), then 
> this message will be lost.
>

 http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#What_happens_to_the_Message

 If the supervisor strategy governing that failure stops the actor 
 without restarting it, then yes the messages in the mailbox will go to 
 DeadLetters.  If the actor is restarted after failure, the mailbox will be 
 unaffected and the new incarnation of the actor will pick up where the 
 dead 
 actor left off (minus the actor that caused the failure).

 On Thursday, October 15, 2015 at 12:31:39 PM UTC-6, Arne Claassen wrote:
>
> The scenario in which this came up was one of a bug causing the death. 
> I.e. it wasn't perceived to be a dangerous operation, I wanted a way to 
> quickly deal with the failure rather than having the sender rely on a 
> timeout.
>
> Clearly it was considered desirable to recover the cause, since 
> preRestart gets the message. Shouldn't it be even more desirable to get 
> the 
> cause (if even just for logging) in the case that the actor is actually 
> stopped?
>
> I guess the real question is, is it intentional that in the case of 
> stopping an actor the message that

[akka-user] Servlet and Actor

2015-10-17 Thread Joseph Mansigian

Is it possible for the same Java class to be both a servlet ( in my case a 
servlet interacting with embedded Jetty ) and an Akka actor.  Is there 
example code for making such a class ?   Thank you.

-- 
>>  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] Servlet and Actor

2015-10-17 Thread Viktor Klang

Hi Joseph,

that would not make sense as it would violate encapsulation of the Actor.
What you can do however is to write a Servlet that sends messages to an
Actor.

On Sat, Oct 17, 2015 at 11:27 PM, Joseph Mansigian <
aed.project.c...@gmail.com> wrote:

> Is it possible for the same Java class to be both a servlet ( in my case a
> servlet interacting with embedded Jetty ) and an Akka actor.  Is there
> example code for making such a class ?   Thank you.
>
> --
> >> 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.
>



-- 
Cheers,
√

-- 
>>  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] Re: Behavior of Akka when you sleep in an actor

[akka-user] No Tests to run for MultiJvm

[akka-user] No Tests to run for MultiJvm

Re: [akka-user] Capturing the message that killed an actor

[akka-user] Fwd: Proposed major simplification of the Akka Streams FlowGraph APIs

Re: [akka-user] Capturing the message that killed an actor

[akka-user] Servlet and Actor

Re: [akka-user] Servlet and Actor

8 matches

Site Navigation

Mail list logo

Footer information