[akka-user] TestProbe() and actorSelection

[Kostas kougios]

Hi, I am trying to test actor code that uses actorSelection:

val path = RootActorPath(member.address, name = "/user/clusterKeeper")
context.actorSelection(path).resolveOne(5 seconds).foreach {
clusterKeeper =>
  clusterKeeper ! msg
}


member.address comes from akka clusters and has the address of the remote 
actor.

Now I need to mock/probe the clusterKeeper actor but TestProbe() doesn't 
have a way of defining the name of the actor or it's path. In fact it goes 
down to TestKitBase where it is hardcoded:

val testActor: ActorRef = {
  val impl = system.asInstanceOf[ExtendedActorSystem]
  val ref = impl.systemActorOf(TestActor.props(queue)
.withDispatcher(CallingThreadDispatcher.Id),

*"testActor" + TestKit.testActorId.incrementAndGet) * awaitCond(ref match {
case r: RepointableRef ⇒ r.isStarted
case _ ⇒ true
  }, 1 second, 10 millis)
  ref
}


Is there a way with the testkit to test this? Ofcourse I could create an 
actor myself but then I would have to reimpl all expectMsg or maybe have it 
forward the messages to testkit. 

Similar post :
https://groups.google.com/forum/#!searchin/akka-user/testprobe$20actorSelection/akka-user/ETL4XQr1Sj4/N9lo_6gc8voJ

-- 
>>  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] Passing ActorRef as Constructor argument is a good practice??

[Hareesh Jagannathan]

I am new to Akka and I am bulding a Data ingestion system as a cluster akka 
system based on (Blancing worker node pattern)with many remote nodes. The 
remote nodes are called workers. Workers create chain of remote routers 
using the available workers.

The parent(Worker) which creates routers will have a stats watcher actor 
who will get message from all routees of routers.

The qn is : Is is good practise to pass statswatcher actorRef while 
creating routers as constructor argument of the router or just pass actor 
path of statswatcher as constructor argument and user actor selection in 
router to tell message.

-- 
>>  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] Flow supervision decider

[David Pratt]

I agree completely - what I guess I'm struggling with (mainly because I haven't 
yet completely grokked the stream API yet) is how to elegantly compose these 
abstractions on top of a stream. The nice thing about a try is that while 
'inside' it, I don't know or care about exception handling. 

Basically, what I guess I'm looking for is a way to author a Flow[A, B, _], and 
have a way to lift it into a Flow[A, Try[B], _]. This, of course doesn't work 
perfectly since there's nothing about a stream that implies a 1:1 correlation 
between inputs and outputs. Of course, you could always just implement it such 
that every successful output is lifted into a Success, and any failure drops 
the current element and emits a  single Failure wrapping the cause. Correlation 
between input elements and Failure on the output could be implemented by the 
user by just ensuring that any thrown exceptions have a reference to the 
relevant data.

Sent from my iPhone

> On May 20, 2015, at 3:13 PM, Viktor Klang  wrote:
> 
> From my PoV:
> 
> It is vital to distinguish "stream fatal errors" from "transient element 
> processing error",
> the first terminates the stream abruptly, the second should be modeled within 
> the processing domain,
> by transmitting things like Try[T] as elements for instance.
> 
>> On Wed, May 20, 2015 at 10:06 PM, Patrik Nordwall 
>>  wrote:
>> One thing to remember is that an upstream failure will be propagated 
>> downstream immediately without backpressure and thereby overtake previously 
>> emitted (buffered) elements, and transforming such an error to an element 
>> further downstream may result in unexpected order of elements.
>> 
>> Another thing is that such a failure will cancel upstream and that will be 
>> difficult to coordinate with a (later) downstream recovery.
>> 
>> It is sure possible to implement for a specific stage, but then it is 
>> perhaps confusing that it is only "catching" errors from the preceding stage.
>> 
>> This is just my 2c, so if you want a real assessment you are welcome to 
>> create a github issue.
>> 
>> /Patrik
>> 
>>> 20 maj 2015 kl. 18:24 skrev dpratt :
>>> 
>>> Sorry - hit send too soon.
>>> 
>>> foo.recover {
>>>   case (NonFatal(e), failedValue) =>
>>>  log.error(e, "Problem processing stream value of {}", failedValue)
>>>  "UNKNOWN VALUE"
>>> }
>>> 
>>> 
 On Wednesday, May 20, 2015 at 11:23:02 AM UTC-5, dpratt wrote:
 What if I have an existing stage/Flow that I do not have control over, or 
 where it would not make sense to conflate the flow logic with the 
 exception handling?
 
 For example
 
 val foo: Flow[String, String, Unit] = 
 SomeLibrary.somethingThatGeneratesAFlow()
 
 how would I wrap foo with error handling? I can't use map or mapAsync, 
 since those are compositional - namely, the value to map has already been 
 calculated. What I really want is a recover block on the flow itself - 
 something like
 
 foo.recover {
 
 }
 
 
 
 
> On Wednesday, May 20, 2015 at 4:37:37 AM UTC-5, Patrik Nordwall wrote:
> I think we considered adding this to the stream supervision mechanism, 
> but since it is not possible to express the types of the elements there 
> in any sane way we decided to not do it. Instead we said that this 
> specific recover scenario should be handled with try-catch within the 
> function/stage of yours. For mapAsync you can use recover on the Future.
> 
> By the way, you can define the supervision for individual stages by using 
> the withAttributes.
> 
> Regards,
> Patrik
> 
>> On Fri, May 15, 2015 at 7:50 PM, dpratt  wrote:
>> I've been using the Streams API to build a few things for the past 
>> couple months, and I have a humble suggestion for an API enhancement. 
>> I'm not sure if this is even possible to do given the contract of how a 
>> Flow operates, adding a method to FlowOps with the following signature 
>> would be quite useful - 
>> 
>> def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]
>> 
>> It's likely due to the fact that I have yet to fully internalize the 
>> Flow API, but I've found that the supervision functionality isn't 
>> exactly what I need. On the top-level, it makes complete sense, but 
>> there is no way to deal with an error in a stream and not have at least 
>> one message silently dropped. It would be nice to be able to set up more 
>> fine-grained error handling. 
>> 
>> As an example, imagine a stream that was processing incoming deltas to a 
>> set of records held either in memory or some persistent data store. A 
>> failure of a given delta should not necessarily shut down the whole 
>> pipeline, but the associated record should be marked as inconsistent and 
>> dealt with appropriately. Using the current supervision API, there's no 
>> way to de

Re: [akka-user] Flow supervision decider

[Viktor Klang]

>From my PoV:

It is vital to distinguish "stream fatal errors" from "transient element
processing error",
the first terminates the stream abruptly, the second should be modeled
within the processing domain,
by transmitting things like Try[T] as elements for instance.

On Wed, May 20, 2015 at 10:06 PM, Patrik Nordwall  wrote:

> One thing to remember is that an upstream failure will be propagated
> downstream immediately without backpressure and thereby overtake previously
> emitted (buffered) elements, and transforming such an error to an element
> further downstream may result in unexpected order of elements.
>
> Another thing is that such a failure will cancel upstream and that will be
> difficult to coordinate with a (later) downstream recovery.
>
> It is sure possible to implement for a specific stage, but then it is
> perhaps confusing that it is only "catching" errors from the preceding
> stage.
>
> This is just my 2c, so if you want a real assessment you are welcome to
> create a github issue.
>
> /Patrik
>
> 20 maj 2015 kl. 18:24 skrev dpratt :
>
> Sorry - hit send too soon.
>
> foo.recover {
>   case (NonFatal(e), failedValue) =>
>  log.error(e, "Problem processing stream value of {}", failedValue)
>  "UNKNOWN VALUE"
> }
>
>
> On Wednesday, May 20, 2015 at 11:23:02 AM UTC-5, dpratt wrote:
>>
>> What if I have an existing stage/Flow that I do not have control over, or
>> where it would not make sense to conflate the flow logic with the exception
>> handling?
>>
>> For example
>>
>> val foo: Flow[String, String, Unit] =
>> SomeLibrary.somethingThatGeneratesAFlow()
>>
>> how would I wrap foo with error handling? I can't use map or mapAsync,
>> since those are compositional - namely, the value to map has already been
>> calculated. What I really want is a recover block on the flow itself -
>> something like
>>
>> foo.recover {
>>
>> }
>>
>>
>>
>>
>> On Wednesday, May 20, 2015 at 4:37:37 AM UTC-5, Patrik Nordwall wrote:
>>>
>>> I think we considered adding this to the stream supervision mechanism,
>>> but since it is not possible to express the types of the elements there in
>>> any sane way we decided to not do it. Instead we said that this specific
>>> recover scenario should be handled with try-catch within the function/stage
>>> of yours. For mapAsync you can use recover on the Future.
>>>
>>> By the way, you can define the supervision for individual stages by
>>> using the withAttributes.
>>>
>>> Regards,
>>> Patrik
>>>
>>> On Fri, May 15, 2015 at 7:50 PM, dpratt  wrote:
>>>
 I've been using the Streams API to build a few things for the past
 couple months, and I have a humble suggestion for an API enhancement. I'm
 not sure if this is even possible to do given the contract of how a Flow
 operates, adding a method to FlowOps with the following signature would be
 quite useful -

 def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]

 It's likely due to the fact that I have yet to fully internalize the
 Flow API, but I've found that the supervision functionality isn't exactly
 what I need. On the top-level, it makes complete sense, but there is no way
 to deal with an error in a stream and not have at least one message
 silently dropped. It would be nice to be able to set up more fine-grained
 error handling.

 As an example, imagine a stream that was processing incoming deltas to
 a set of records held either in memory or some persistent data store. A
 failure of a given delta should not necessarily shut down the whole
 pipeline, but the associated record should be marked as inconsistent and
 dealt with appropriately. Using the current supervision API, there's no way
 to determine the actual element that caused the failure, and thus there's
 no real way to handle it or signal an external system with the details of
 the error.

 Of course, you can work around this by making the stream operate on a
 Try[T] instead of T, but that just seems unwieldy.

 Am I looking at this the wrong way?

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

>>>
>>>
>>>
>>> --
>>>
>>> Patrik Nordwall
>>> Typesafe  -  Reactive apps on the JVM
>>> Twitter: @patriknw
>>>
>>>   --
> >> Read the docs: http://akka.io/docs/
> >> 

Re: [akka-user] Flow supervision decider

[Patrik Nordwall]

One thing to remember is that an upstream failure will be propagated downstream 
immediately without backpressure and thereby overtake previously emitted 
(buffered) elements, and transforming such an error to an element further 
downstream may result in unexpected order of elements.

Another thing is that such a failure will cancel upstream and that will be 
difficult to coordinate with a (later) downstream recovery.

It is sure possible to implement for a specific stage, but then it is perhaps 
confusing that it is only "catching" errors from the preceding stage.

This is just my 2c, so if you want a real assessment you are welcome to create 
a github issue.

/Patrik

> 20 maj 2015 kl. 18:24 skrev dpratt :
> 
> Sorry - hit send too soon.
> 
> foo.recover {
>   case (NonFatal(e), failedValue) =>
>  log.error(e, "Problem processing stream value of {}", failedValue)
>  "UNKNOWN VALUE"
> }
> 
> 
>> On Wednesday, May 20, 2015 at 11:23:02 AM UTC-5, dpratt wrote:
>> What if I have an existing stage/Flow that I do not have control over, or 
>> where it would not make sense to conflate the flow logic with the exception 
>> handling?
>> 
>> For example
>> 
>> val foo: Flow[String, String, Unit] = 
>> SomeLibrary.somethingThatGeneratesAFlow()
>> 
>> how would I wrap foo with error handling? I can't use map or mapAsync, since 
>> those are compositional - namely, the value to map has already been 
>> calculated. What I really want is a recover block on the flow itself - 
>> something like
>> 
>> foo.recover {
>> 
>> }
>> 
>> 
>> 
>> 
>>> On Wednesday, May 20, 2015 at 4:37:37 AM UTC-5, Patrik Nordwall wrote:
>>> I think we considered adding this to the stream supervision mechanism, but 
>>> since it is not possible to express the types of the elements there in any 
>>> sane way we decided to not do it. Instead we said that this specific 
>>> recover scenario should be handled with try-catch within the function/stage 
>>> of yours. For mapAsync you can use recover on the Future.
>>> 
>>> By the way, you can define the supervision for individual stages by using 
>>> the withAttributes.
>>> 
>>> Regards,
>>> Patrik
>>> 
 On Fri, May 15, 2015 at 7:50 PM, dpratt  wrote:
 I've been using the Streams API to build a few things for the past couple 
 months, and I have a humble suggestion for an API enhancement. I'm not 
 sure if this is even possible to do given the contract of how a Flow 
 operates, adding a method to FlowOps with the following signature would be 
 quite useful - 
 
 def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]
 
 It's likely due to the fact that I have yet to fully internalize the Flow 
 API, but I've found that the supervision functionality isn't exactly what 
 I need. On the top-level, it makes complete sense, but there is no way to 
 deal with an error in a stream and not have at least one message silently 
 dropped. It would be nice to be able to set up more fine-grained error 
 handling. 
 
 As an example, imagine a stream that was processing incoming deltas to a 
 set of records held either in memory or some persistent data store. A 
 failure of a given delta should not necessarily shut down the whole 
 pipeline, but the associated record should be marked as inconsistent and 
 dealt with appropriately. Using the current supervision API, there's no 
 way to determine the actual element that caused the failure, and thus 
 there's no real way to handle it or signal an external system with the 
 details of the error.
 
 Of course, you can work around this by making the stream operate on a 
 Try[T] instead of T, but that just seems unwieldy. 
 
 Am I looking at this the wrong way?
 -- 
 >> 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+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> 
>>> 
>>> -- 
>>> Patrik Nordwall
>>> Typesafe -  Reactive apps on the JVM
>>> Twitter: @patriknw
>>> 
> 
> -- 
> >> 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 email

[akka-user] Am I doing it wrong?

[Anton Khodakivskiy]

Hi

I've recently attempted to build a bitcoin trading bot for Coinbase
exchange. At first using Actors felt natural for this sort of problem.
There is asynchronous incoming and outgoing messages (exchange tick data,
placing, cancelling orders), a lot of state (managing order book, following
own orders), all the auxiliary tools that introduce even more state and
more interactions (simulator for backtesting).

My current actor implementation involves 5-7 actors that send one another
messages. Coding the system was fun and it seems to work fast enough (in
simulation mode I can process 1 exchange message in 50 mics on average).
But... the resulting system is not deterministic. There are many actors,
significant message flow. This results in all sorts of race conditions. One
of the manifestations of this problem is that the backtest results between
the runs are drastically different. It almost seems like butterfly effect -
one actor sends a message a tad earlier and all the subsequent order flow
is totally different.

I started addressing these race conditions, and after a while I realized
that my system is now deterministic and... completely linear. After this I
ditched Akka and reimplemented everything in conventional Scala, employing
some category theory tricks. State monad in particular turned out to be
quite useful. It's also worth noting that message processing time went down
from 50 mics to ~10, which allows me to run backtests 5 times faster.

Now my questions: is there a chance that I misunderstood and misused the
actor model? Or is it the nature of my problem (trading bot) that doesn't
really require such a sophisticated solution as actor model? What kind of
problems can actually benefit from using actors? Is there good open source
example projects to learn from?

Thanks,

Anton

-- 
>>  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] Flow supervision decider

[dpratt]

Sorry - hit send too soon.

foo.recover {
  case (NonFatal(e), failedValue) =>
 log.error(e, "Problem processing stream value of {}", failedValue)
 "UNKNOWN VALUE"
}


On Wednesday, May 20, 2015 at 11:23:02 AM UTC-5, dpratt wrote:
>
> What if I have an existing stage/Flow that I do not have control over, or 
> where it would not make sense to conflate the flow logic with the exception 
> handling?
>
> For example
>
> val foo: Flow[String, String, Unit] = 
> SomeLibrary.somethingThatGeneratesAFlow()
>
> how would I wrap foo with error handling? I can't use map or mapAsync, 
> since those are compositional - namely, the value to map has already been 
> calculated. What I really want is a recover block on the flow itself - 
> something like
>
> foo.recover {
>
> }
>
>
>
>
> On Wednesday, May 20, 2015 at 4:37:37 AM UTC-5, Patrik Nordwall wrote:
>>
>> I think we considered adding this to the stream supervision mechanism, 
>> but since it is not possible to express the types of the elements there in 
>> any sane way we decided to not do it. Instead we said that this specific 
>> recover scenario should be handled with try-catch within the function/stage 
>> of yours. For mapAsync you can use recover on the Future.
>>
>> By the way, you can define the supervision for individual stages by using 
>> the withAttributes.
>>
>> Regards,
>> Patrik
>>
>> On Fri, May 15, 2015 at 7:50 PM, dpratt  wrote:
>>
>>> I've been using the Streams API to build a few things for the past 
>>> couple months, and I have a humble suggestion for an API enhancement. I'm 
>>> not sure if this is even possible to do given the contract of how a Flow 
>>> operates, adding a method to FlowOps with the following signature would be 
>>> quite useful - 
>>>
>>> def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]
>>>
>>> It's likely due to the fact that I have yet to fully internalize the 
>>> Flow API, but I've found that the supervision functionality isn't exactly 
>>> what I need. On the top-level, it makes complete sense, but there is no way 
>>> to deal with an error in a stream and not have at least one message 
>>> silently dropped. It would be nice to be able to set up more fine-grained 
>>> error handling. 
>>>
>>> As an example, imagine a stream that was processing incoming deltas to a 
>>> set of records held either in memory or some persistent data store. A 
>>> failure of a given delta should not necessarily shut down the whole 
>>> pipeline, but the associated record should be marked as inconsistent and 
>>> dealt with appropriately. Using the current supervision API, there's no way 
>>> to determine the actual element that caused the failure, and thus there's 
>>> no real way to handle it or signal an external system with the details of 
>>> the error.
>>>
>>> Of course, you can work around this by making the stream operate on a 
>>> Try[T] instead of T, but that just seems unwieldy. 
>>>
>>> Am I looking at this the wrong way?
>>>
>>> -- 
>>> >> 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+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>>
>> Patrik Nordwall
>> Typesafe  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>>  

-- 
>>  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] Flow supervision decider

[dpratt]

What if I have an existing stage/Flow that I do not have control over, or 
where it would not make sense to conflate the flow logic with the exception 
handling?

For example

val foo: Flow[String, String, Unit] = 
SomeLibrary.somethingThatGeneratesAFlow()

how would I wrap foo with error handling? I can't use map or mapAsync, 
since those are compositional - namely, the value to map has already been 
calculated. What I really want is a recover block on the flow itself - 
something like

foo.recover {

}




On Wednesday, May 20, 2015 at 4:37:37 AM UTC-5, Patrik Nordwall wrote:
>
> I think we considered adding this to the stream supervision mechanism, but 
> since it is not possible to express the types of the elements there in any 
> sane way we decided to not do it. Instead we said that this specific 
> recover scenario should be handled with try-catch within the function/stage 
> of yours. For mapAsync you can use recover on the Future.
>
> By the way, you can define the supervision for individual stages by using 
> the withAttributes.
>
> Regards,
> Patrik
>
> On Fri, May 15, 2015 at 7:50 PM, dpratt > 
> wrote:
>
>> I've been using the Streams API to build a few things for the past couple 
>> months, and I have a humble suggestion for an API enhancement. I'm not sure 
>> if this is even possible to do given the contract of how a Flow operates, 
>> adding a method to FlowOps with the following signature would be quite 
>> useful - 
>>
>> def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]
>>
>> It's likely due to the fact that I have yet to fully internalize the Flow 
>> API, but I've found that the supervision functionality isn't exactly what I 
>> need. On the top-level, it makes complete sense, but there is no way to 
>> deal with an error in a stream and not have at least one message silently 
>> dropped. It would be nice to be able to set up more fine-grained error 
>> handling. 
>>
>> As an example, imagine a stream that was processing incoming deltas to a 
>> set of records held either in memory or some persistent data store. A 
>> failure of a given delta should not necessarily shut down the whole 
>> pipeline, but the associated record should be marked as inconsistent and 
>> dealt with appropriately. Using the current supervision API, there's no way 
>> to determine the actual element that caused the failure, and thus there's 
>> no real way to handle it or signal an external system with the details of 
>> the error.
>>
>> Of course, you can work around this by making the stream operate on a 
>> Try[T] instead of T, but that just seems unwieldy. 
>>
>> Am I looking at this the wrong way?
>>
>> -- 
>> >> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
>  

-- 
>>  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] Messages simultaneously sended to Dead Letters and to destination Actor

[Patrik Nordwall]

I'm pretty sure that there is something in your code that cause the
duplication, but it is a bit too much code for me to review/debug. Try to
narrow it down, and if you find a small test that can reproduce the problem
we would be happy to fix it.

Thanks,
Patrik

On Wed, May 20, 2015 at 11:43 AM, Antonio Benvenuto  wrote:

> Hi Martynas
>
> I am sure that COORDINATOR_ACTOR does not duplicate messages.
> I have noticed that number of dead letters rise when I try to increment
> number of simultaneous request messages to GATE_ACTOR.
>
> Here you can see the code of example:
> *GATE_ACTOR_INTERFACE:  *
> http://paste.ofcode.org/3b3CVPNr9gRQErN3Dheujq9
> *GATE ACTOR IMPLEMENTATION:*
> http://paste.ofcode.org/prQqWKSLNKM2HbvqVaddQQ
> *COORDINATOR_ACTOR:*http://paste.ofcode.org/UUSG42gKuD3afSLwNz3tQa
> *FIRST_JOB_ACTOR:*  http://paste.ofcode.org/92XHTavpMAdNtXxCupcBCq
> *SECOND_JOB_ACTOR:*  http://paste.ofcode.org/YeUFDcmZzBFA3umVg2yHwE
> *THIRD_JOB_ACTOR: * http://paste.ofcode.org/Vh9aSmUpgbjG6ReDffhrhV
>
> *POPERTIES:   *
> http://paste.ofcode.org/JUcfA8FDUxmrEh5q7aPYfv
> *TEST:*
> http://paste.ofcode.org/CyFQUe3hPBfQYQWiGCKLK
>
> This is the architecture of my actors system
>
>
> 
>
> Thank you
>
> Antonio
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] End-to-End Reactive Streaming RESTful service (a.k.a. Back-Pressure over HTTP)

[Konrad Malawski]

The back pressure is propagated to the client thanks to TCPs built in 
mechanisms for this - on the server side we simply do not read from the socket
until demand is available, which causes the back pressure to be propagated 
properly.

Konrad, 

So if we are *not* using a congestion control aware protocol such as TCP, the 
back pressure won't work propagate though network boundaries. Correct? 
If you use a protocol that is unable to perform congestion control, you will 
not have congestion control over that medium - correct :-)

There is an effort to implement the reactive streams semantics to an 
on-the-wire protocol, https://github.com/reactive-streams/reactive-streams-io 
but it’s not yet under heavy development. In this case both ends need to 
understand and speak the reactive streams protocol on wire level. It would 
allow using any kind of transport layer - we could ditch TCP then.


Is there a way to build this easily using Akka-streams/reactive-streams ? 
With TCP it just works. For the network protocol see the link above, there will 
be work done around it soon.





-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ 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.

Re: [akka-user] End-to-End Reactive Streaming RESTful service (a.k.a. Back-Pressure over HTTP)

[Matteo De Martino]

Thanks very much Konrad!

Very interesting videos; I will try experimenting more now.

Do you want to post you answer on SO as well? I originally posted it 
there...
http://stackoverflow.com/questions/30298972/end-to-end-reactive-streaming-restful-service-a-k-a-back-pressure-over-http

Thanks!
Matteo

Il giorno lunedì 18 maggio 2015 11:59:09 UTC+1, Konrad Malawski ha scritto:
>
> Hi there Matteo,
> You’ve arrived in the right place to ask Akka questions :-)
>
> There are two talks I’m aware of which show a demo how the backpressure 
> mechanism really works when working with http.
> 1) One is Roland Kuhn’s talk on ScalaDays  SF 2015: 
> https://www.parleys.com/tutorial/akka-http-reactive-web-toolkit
> the backpressure over http demo starts around the 44th minute of this talk.
>
> 2) My talk from ScalarConf  Warsaw 2015: 
> https://www.youtube.com/watch?v=WnTSuYL4_wU the streams part begins 
> around the 18 minute,
> and the backpressuring demo is seen around the 24th minute 
> . It shows a “fast processing” and 
> “slow processing” server, in which you can see the
> curl client being backpressured when the file is being uploaded (I use a 
> file as an example because it’s a nice “big request”).
>
> The back pressure is propagated to the client thanks to TCPs built in 
> mechanisms for this - on the server side we simply do not read from the 
> socket
> until demand is available, which causes the back pressure to be propagated 
> properly.
>
> I hope this helps!
>
> -- 
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Typesafe 
>
> On 18 May 2015 at 12:44:49, Matteo De Martino (emme...@gmail.com 
> ) wrote:
>
>  I have been trying to clarify this question online for a while without 
> success, so I will try to ask it here.
>
> I would like to find some resource or example where it shows how I can 
> build an end-to-end fully back-pressured REST service + client. What I mean 
> is that I would like to see that, given a REST client that implements 
> Reactive Streams (whether in Akka, JS, or whatever), I will have (and be 
> able to "visualise") the back-pressure handled throughout a REST server 
> built, e.g. with Akka-Http.
>
> To be clear, I am searching for something like the following talk (but I 
> could not find slides or videos to confirm it): 
> http://oredev.org/2014/sessions/reactive-streaming-restful-applications-with-akka-http
>
> My doubts with most examples I see are about the fact that I can find 
> plenty cases where the REST service (server) is using Akka Http and Akka 
> streams for the back end, but I am not sure that the backpressure is 
> "communicated" over HTTP and REST, if the client is implementing Reactive 
> Streams. In such situation, would I have a single "stream" bridged over 
> TCP/HTTP or just 2 independent streams? That is my main doubt and confusion.
>
> Hopefully I was clear enough and someone will be able to shed some light 
> on the matter.
> In any case, 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+...@googlegroups.com .
> To post to this group, send email to akka...@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] Advantages and disadvantages of using 2 ActorSystem

[Patrik Nordwall]

I would recommend using the Play actor system instead of your own – Play
ensures that the actor system's lifecycle is correctly managed, that the
right classloader is used, etc etc, all for you. If you don’t use Play’s
actor system, then you will need to manage this yourself, or you will have
out of memory problems when using Play's reloading mechanism in development
mode.

/Patrik


On Tue, May 19, 2015 at 6:10 PM, Dragisa Krsmanovic 
wrote:

> Play already has two actor systems. One called "play" for internal use of
> Play framework and one called "application" that you can access via
> play.api.libs.concurrent.Akka for you to use.
>
>
>
> On Tue, May 19, 2015 at 1:42 AM, Gabriele Favaretto <
> gabriele.favare...@databiz.it> wrote:
>
>> In a Play application, would be the advantages of using a different
>> ActorSystem respect the Play one?
>> Are there any production environments where using another ActorSystem was
>> useful or necessary?
>>
>> --
>> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] TestKit and how to avoid a failing (or sucesful) test affecting the other tests

[Konstantinos Kougios]

Thanks Martynas, withFixture looks promising. I've managed to sort out 
my tests so far even with sharing TestKit but if I get into troubles 
again I will try it.


On 16/05/15 09:48, Martynas Mickevičius wrote:

Hi Kostas,

I think that tools provided by ScalaTest for code reuse could help 
you. For example by overriding withFixture you can have a new instance 
of TestKit for every test.


I want to also mention that in carefully crafted tests cases sharing 
the same testActor can be helpful as well. In such case a not-expected 
message received by testActor would indicate a bug somewhere in the 
program.


Hope this helps.

On Tue, May 12, 2015 at 6:22 PM, Kostas kougios 
mailto:kostas.koug...@googlemail.com>> 
wrote:


Hi,

I am having this issue where I sometimes "tell" different actors
multiple messages and I want to test a single message, so I might
have 1 expectMsg. But then, this affects the rest of the tests
,i.e. if the receiver is the testActor.

is there a way to "reset" TestKit for each test?

Thanks

(Note: i've asked a more detailed question similar to this but it
is probably too complex and didn't get any answers yet)
-- 
>> 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  – Reactive 
 Apps 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 a topic in the 
Google Groups "Akka User List" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/akka-user/GV6mkXSHsHk/unsubscribe.
To unsubscribe from this group and all its topics, 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] Messages simultaneously sended to Dead Letters and to destination Actor

[Antonio Benvenuto]

Hi Martynas

I am sure that COORDINATOR_ACTOR does not duplicate messages. 
I have noticed that number of dead letters rise when I try to increment 
number of simultaneous request messages to GATE_ACTOR.

Here you can see the code of example:
*GATE_ACTOR_INTERFACE:  *
http://paste.ofcode.org/3b3CVPNr9gRQErN3Dheujq9
*GATE ACTOR IMPLEMENTATION:*
http://paste.ofcode.org/prQqWKSLNKM2HbvqVaddQQ
*COORDINATOR_ACTOR:*http://paste.ofcode.org/UUSG42gKuD3afSLwNz3tQa
*FIRST_JOB_ACTOR:*  http://paste.ofcode.org/92XHTavpMAdNtXxCupcBCq
*SECOND_JOB_ACTOR:*  http://paste.ofcode.org/YeUFDcmZzBFA3umVg2yHwE
*THIRD_JOB_ACTOR: * http://paste.ofcode.org/Vh9aSmUpgbjG6ReDffhrhV

*POPERTIES:   *   
http://paste.ofcode.org/JUcfA8FDUxmrEh5q7aPYfv
*TEST:* 
http://paste.ofcode.org/CyFQUe3hPBfQYQWiGCKLK

This is the architecture of my actors system



Thank you

Antonio

-- 
>>  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] Can the actor in an actor model system be singleton?

[Patrik Nordwall]

On Sat, May 16, 2015 at 10:12 PM, wonderful world 
wrote:

> In an actor model system, for example in a product catalog, there can be
> thousands of actors for products - *Product A* is one actor and *Product
> B* is another actor.
>
> There can be another *DiscountCalculatorActor* which finds the discount
> for a product and it can be a child actor of that product. It can also be a
> single actor serving thousands of actors.
> What is the best pattern to handle the above case? Can the
> *DiscountCalculatorActor* be a singleton actor or a child actor of every
> product actor?
>

If you only have one DiscountCalculatorActor it will processes the requests
in sequence, one-by-one. That might be a bottleneck. or it might not be a
problem?

If this is like a stateless service it might make sense to not have one for
each product, but have one or a few of them.

In other words, it all depends

/Patrik


>
>  --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] Flow supervision decider

[Patrik Nordwall]

I think we considered adding this to the stream supervision mechanism, but
since it is not possible to express the types of the elements there in any
sane way we decided to not do it. Instead we said that this specific
recover scenario should be handled with try-catch within the function/stage
of yours. For mapAsync you can use recover on the Future.

By the way, you can define the supervision for individual stages by using
the withAttributes.

Regards,
Patrik

On Fri, May 15, 2015 at 7:50 PM, dpratt  wrote:

> I've been using the Streams API to build a few things for the past couple
> months, and I have a humble suggestion for an API enhancement. I'm not sure
> if this is even possible to do given the contract of how a Flow operates,
> adding a method to FlowOps with the following signature would be quite
> useful -
>
> def recover(f: PartialFunction[(In, Throwable), Out]): Repr[Out, Mat]
>
> It's likely due to the fact that I have yet to fully internalize the Flow
> API, but I've found that the supervision functionality isn't exactly what I
> need. On the top-level, it makes complete sense, but there is no way to
> deal with an error in a stream and not have at least one message silently
> dropped. It would be nice to be able to set up more fine-grained error
> handling.
>
> As an example, imagine a stream that was processing incoming deltas to a
> set of records held either in memory or some persistent data store. A
> failure of a given delta should not necessarily shut down the whole
> pipeline, but the associated record should be marked as inconsistent and
> dealt with appropriately. Using the current supervision API, there's no way
> to determine the actual element that caused the failure, and thus there's
> no real way to handle it or signal an external system with the details of
> the error.
>
> Of course, you can work around this by making the stream operate on a
> Try[T] instead of T, but that just seems unwieldy.
>
> Am I looking at this the wrong way?
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] Looking for the right remoting config to tune when 'unreachable' is not an error - to stop connecting after configurable duration

[Patrik Nordwall]

Hi Helena,

First we must try to understand what is sending messages to the
downed/removed nodes.
After you have killed the B node the cluster failure detector will trigger
and then I assume that you use some Cluster downing mechanism to remove the
old B node from the cluster. Until that point it is expected that you will
see these logs, because failure detector heartbeat messages will continue
until the node is removed. After removal these log messages should stop,
unless you continue to send something yourself.

Perhaps you can debug the messages with the settings described here:
http://doc.akka.io/docs/akka/2.3.11/scala/logging.html#Auxiliary_remote_logging_options

You are using Akka 2.3.11, right?

Cheers,
Patrik

On Thu, May 14, 2015 at 10:21 PM, Helena Edelson <
helena.edel...@datastax.com> wrote:

> Hi,
>
> I am looking for the right remoting config to tune for expected
> unreachable behavior when a node goes down, to not continue past n-duration
> to keep trying to connect. For what I'm doing it can be perfectly normal
> for a node to go down and come up again. It's chaos monkey friendly.
>
> This is the known logging, that I want to prevent the cause of when
> expected: I see it go on forever vs stop after a certain period:
> WARN  19:50:12 Tried to associate with unreachable remote address
> [akka.tcp://system@host:port]. Address is now gated for 1000 ms, all
> messages to this address will be delivered to dead letters. Reason:
> Connection refused: /host:port
>
> I have a cluster of 2 roles, say nodes of roles A and B. I have a node of
> role A running, and as I bringing role B nodes up and down ( in lifecycle
> testing),  I want nodes of role A to not interpret the remoting 'Connection
> refused' as an error but to simply stop attempting to use it, to forget
> about the address/port completely. A downed node will come back with a new
> port. So it's not the cluster MemberRemoved and Unreachable events, just
> seems the remoting configuration I need to add/modify.
>
> What might that be? I've been trying a few things, nothing clicking yet ;)
>
> Thanks,
> Helena
> @helenaedelson
>
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] Erratic latency behaviour

[Patrik Nordwall]

Hi Maarten,

It's hard to guess what is causing that latency distribution. I would try
to correlate it with GC pauses on all 3 JVMs. You can use flags like
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps.

Make sure you use the latest version, i.e. 2.3.11.

Regards,
Patrik

On Mon, May 11, 2015 at 6:03 PM, Maarten Decat 
wrote:

> Hi all,
>
> I'm currently using Akka for building a scalable system for distributed
> rule evaluation. The focus is on throughput and scalability with respect to
> the number of nodes, and it's amazing how quickly Akka allows to set up a
> working and scalable distributed system.
>
> However, I have hit some strange behaviour in terms of the latency of
> individual requests. As the graph below shows, the large majority of the
> requests is around 2-3 ms, which is great. 13% of the requests however make
> up another peak, this one around 44ms.
>
>
> 
>
> Since this amount skewes the final results of my performance tests, I'm
> trying to solve this issue, but have not found a solution yet and wanted to
> see whether any of you have an idea where to look.
>
>
> To give some more details:
>
> - The requests measured in the graph are actually the end-to-end latencies
> of 6 sequential messages between 3 different actors on 3 different JVMs
> located on a single physical node (my laptop). The same behavior occurs
> when deploying these JVMs on different physical machines.
>
> - The three nodes are a client and 2 cooperating coordinator nodes,
> resulting in a message flow as follows: A -> B -> C -> B -> C -> B -> A.
>
> - After measuring the latency of each individual message, it seems that
> the vast majority of the high end-to-end latencies are caused by the first
> message from B -> C, which takes up around 36ms then. In other words, the
> 13% is the result of around 13/6=2.2% of the messages showing a high
> latency.
>
> - The messages are Scala case classes for which I use the default
> serialized (no protobuf or JSON).
>
> - Remoting is done using Netty/TCP as shown in the examples on the website.
>
> - I have not configured any specific dispatchers in the conf.
>
> - The measurements in the graph shown above are taken sequentially,
> meaning that A makes a request, waits time for B to respond back to it
> after coordinating with C, and then sends another request.
>
>
> The last days I have tried multiple possible causes, that all failed to
> convince.
>
> - Garbage collection: there are a factor more high-latency requests than
> GCs shown in JVisualVM and their pause time is far below the 36ms. Also,
> adjusting the initial or maximum heap size does not solve the issue.
>
> - (De)serialization: I measured the serialization and deserialization time
> in EndpointWriter and DefaultMessageDispatcher in Endpoint.scala of
> akka-remote, but they never reached more than 1ms. As the timestamps
> showed, the latency is present between serialization in EndpointWriter and
> deserialization in DefaultMessageDispatcher.
>
> - TCP bundling (Nagle's algorithm): setting on tcp-no-deloy in the
> configuration does not fix the issue (and it is default on, no?).
>
> Strangely enough, the percentage of high-latency requests drops if I
> increase the parallel load on the system: for 10 parallel clients as above,
> it's only 2% of the requests, for 20 only 0.6%.
>
> So, for those who made it to the end of this lengthy e-mail: does anyone
> have a clue where I can continue searching for the issue? What happens
> between sending and receiving an Akka message? Is it possible that this has
> something to do with thread scheduling, for example that other threads get
> priority over the thread that is responsible for actually sending or
> receiving the data?
>
> Thanks in advance for any ideas.
>
> Kind regards,
>
> Maarten
>
>  --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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 

Re: [akka-user] How to handle long GC in AKKA Actor model system

[seetaramayya vadali]

Thanks a lot for your valuable inputs. I understood what to do.

Regards,
Seeta

On Tue, May 19, 2015 at 8:31 PM, Michael Frank 
wrote:

>  patrik answered this much better than i could have :)  i was thinking
> that your experience would be better if you could tune the JVM to be more
> responsive.  but you're right, it didn't directly address your original
> question, sorry for the confusion.
>
> i will note, since you're on java7, you might look into the G1 collector
> in order to reduce your GC pauses:
> http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
> .
>
> some documentation on tuning G1:
> http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html
>
> -Michael
>
>
> On 05/18/15 12:19, seetaramayya vadali wrote:
>
>
>- We are using Java 7
>- 32 cores I guess ( I am not sure though )
>- Considering Azul
>
> I didnt understand how come GC tuning matters with node joining the
> cluster. Is there any relation ?
>
>
>
> On Mon, May 18, 2015 at 9:12 PM, Michael Frank 
> wrote:
>
>>  On 05/18/15 11:48, seetaramayya vadali wrote:
>>
>> Hi Martynas,
>>
>>   After adding acceptable-heartbeat-pause and removing
>> auto-down-unreachable-after  both nodes formed different clusters. I am
>> still exploring failure-detector configuration part. If any one have any
>> other suggestions I can save some time :) .
>>
>>   Thanks a lot to every response to this thread.
>>
>>
>>  * What java version are you using?
>> * How many cpu cores are available to you?
>> * What sort of garbage collection tuning have you done and what are your
>> current GC parameters?
>>
>> a 30 minute stop-the-world GC pause seems crazy, but i've never seen a
>> host with 1TB of memory :)
>>
>> -Michael
>>   --
>> >> 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/9ZSFvxegNUY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>>
>
>
>
>  --
> Regards,
> Seeta Ramayya Vadali
>  --
> >> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/9ZSFvxegNUY/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>



-- 
Regards,
Seeta Ramayya Vadali

-- 
>>  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.