Re: [akka-user] Re: Question about kaka-http websocket client

[Filipp Eritsian]

Thanks for looking into this Johan!

On Friday, March 11, 2016 at 1:49:38 AM UTC+11, Akka Team wrote:
>
> After looking closer at this, the reason is that when the Source 
> completes, the socket gets closed and this is because websockets do not 
> really support half-closed mode, where only one direction is still open. 
> The more or less exact six second before closing is caused by two of the 
> hardcoded 3-second timeouts inside of the websocket protocol stack in Akka 
> HTTP. 
>
> We are discussing if we can provide a nice API to hide this, but have not 
> arrived on a decision yet. To avoid this you can make sure the source does 
> not complete until you want it to, for example by using Source.maybe like 
> this:
>
>
> val outgoing = 
> Source.single(TextMessage("out")).concatMat(Source.maybe)(Keep.right)
>
>
> This will materialize into a promise that you can complete or fail 
> whenever you want to kill the connection from the client side.
>
> --
> Johan Andrén
> Akka Team, Lightbend 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Scheduler overflow

[Eric Cartner]

I've got a scheduler test that seems to reproduce what I'm seeing in my 
application. On my Macbook I was unable to place the test inside 
LightArrayRevolverSchedulerSpec because the total test time went over 60s 
and triggered all sorts of alarms and what not. So I just created a new 
spec class and copied the bits I need from LARSSpec. The file is here 
.

"correctly wrap around ticks" in {
  val numEvents = 16
  
  // val targetTicks = Int.MaxValue - numEvents - 2   // Passes
  val targetTicks = Int.MaxValue - numEvents - 1// Fails

  val cfg = ConfigFactory.parseString("akka.scheduler.tick-duration=2ms")
  withScheduler(config = cfg) { (sched, driver) ⇒
implicit def ec = localEC
import driver._

val start = step / 2

wakeUp(step * targetTicks)
probe.expectMsgType[Long](50 seconds)

val nums = 0 until numEvents
nums foreach (i ⇒ sched.scheduleOnce(start + step * i, testActor, 
"hello"))
expectNoMsg(step)
wakeUp(step)
expectWait(step)
nums foreach { _ ⇒
  wakeUp(step)
  expectMsg("hello")
  expectWait(step)
}
  }
}



It follows the same pattern as "correctly wrap around wheel rounds" and 
"correctly execute jobs when clock wraps around". The key difference being 
it makes a long call to *wakeUp* to get the "time" close to the point of 
interest. As noted in the comment the test can pass or fail based on the 
value of *targetTicks*.

 




On Thursday, April 28, 2016 at 8:23:48 AM UTC-5, Patrik Nordwall wrote:
>
> It would be great if you can create a reproducer in the SchedulerSpec: 
> https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/actor/SchedulerSpec.scala
>
> I think it has a way to drive the clock: 
> https://github.com/akka/akka/blob/master/akka-actor-tests/src/test/scala/akka/actor/SchedulerSpec.scala#L525
>
> /Patrik
>
> On Thu, Apr 28, 2016 at 2:23 PM, Eric Cartner  > wrote:
>
>> What information can I provide to help out?
>>
>> On Thursday, April 28, 2016 at 5:11:39 AM UTC-5, Konrad Malawski wrote:
>>>
>>> Yes, the reported issue is might be real and I'd like to get more info 
>>> on it to investigate, I was arguing against the suggestion made to increase 
>>> the range of the scheduler.
>>>
>>> -- 
>>> Konrad `ktoso` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 28 April 2016 at 12:10:03, Patrik Nordwall (patrik@gmail.com) 
>>> wrote:
>>>
>>> If I have not misunderstood the reported issue this is not about 
>>> scheduling something 50 days into the future, but after 50 days the 
>>> scheduler stops working. Scheduled tasks were typically around 8 ms.
>>>
>>> On Thu, Apr 28, 2016 at 12:07 PM, Konrad Malawski <
>>> konrad@lightbend.com> wrote:
>>>
 Is 50 days long enough? I think there is no right or wrong answer to 
 that,
 a quick solution maybe will be to change from Integer to Long which 
 will be an easy fix with a minimal effort, that should extend it to like 
 500 days or more?

 No, because for long term scheduling you want to make sure the thing 
 gets executed – i.e. you need persistence of the events, and also handling 
 things like "it should have triggered in the past, but a node died, before 
 doing it, so we need to run it now".

 These are design goals completely different from the Akka scheduler 
 which is geared towards lots and lots of short and very quickly 
 added/removed timeouts – think about all the ask timeouts in the system, 
 there's tens of thousands of those and they last a few seconds.


 So there seems to be something wrong indeed, let's investigate, however 
 it is not a goal to make the scheduler handle very large intervals – 50 
 days is too much already one might argue actually, but we don't restrain 
 more because why would we :)

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

>>>
>>>
>>>
>>> --
>>>
>>> Patrik Nordwall
>>> Akka Tech Lead
>>> Lightbend  -  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 

[akka-user] Call a function on overflow

[Tim Harper]

A pretty common thing I've to do is to call a (non-blocking, brief) 
callback in the event of an overflow. Usually to send a quick message to 
the logger.

Here's how I normally solve the problem:

  val (input, completed) = Source.actorRef[Int](0, 
OverflowStrategy.dropNew).
conflate { (prior, overflown) =>
  println(s"dropping overflown ${overflown}")
  prior
}.
buffer(10, OverflowStrategy.backpressure).
async.
toMat(Sink.foreach { n =>
  println(n)
  Thread.sleep(100)
})(Keep.both).
run

  (1 to 50).foreach { n =>
input ! n
println(s"sent ${n}")
Thread.sleep(10)
  }


(full source here 
)

But this is rather verbose. Is there a more concise way to have support 
behavior?

Another problem with this approach is that I'm creating two async 
boundaries being created (after the actorRef, and then after the conflate); 
that's less efficient than I'd prefer.

Is the best way to do this is to create a custom ActorSubscriber ?

Tim

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

Re: [akka-user] Re: Node quarantined

[Benjamin Black]

This is the latest version of akka for java 7. 

On Friday, April 29, 2016 at 3:18:55 PM UTC-4, Patrik Nordwall wrote:
>
> There can be several reasons, but a good start is to use latest Akka 
> version.
> tors 28 apr. 2016 kl. 21:13 skrev Guido Medina  >:
>
>> Hi Ben,
>>
>> As my experience goes Netty 3 doesn't get much love, issues are barely 
>> fixed,
>> like I mentioned before I'm running my own Netty 3.10.6 built internally, 
>> also; 3.10.0 is not even a good version,
>> if you want force your version to 3.10.5.Final until they release 
>> 3.10.6.Final which has nice fixes.
>>
>> or
>>
>> you could get my branch, set the version to whatever is comfortable for 
>> you and build your own Netty,
>>
>> My branch: https://github.com/guidomedina/netty/commits/3.10-SFS
>>
>> has the following milestone: 
>> https://github.com/netty/netty/issues?q=milestone%3A3.10.6.Final+is%3Aclosed
>>
>> plus some minor fixes I added myself, as of interest there is a race 
>> condition fixed at 3.10.6 and
>> I saw another between 3.10.0 and 3.10.5 which might be causing the issue 
>> you are experiencing.
>>
>> HTH,
>>
>> Guido.
>>
>> -- 
>> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Node quarantined

[Patrik Nordwall]

There can be several reasons, but a good start is to use latest Akka
version.
tors 28 apr. 2016 kl. 21:13 skrev Guido Medina :

> Hi Ben,
>
> As my experience goes Netty 3 doesn't get much love, issues are barely
> fixed,
> like I mentioned before I'm running my own Netty 3.10.6 built internally,
> also; 3.10.0 is not even a good version,
> if you want force your version to 3.10.5.Final until they release
> 3.10.6.Final which has nice fixes.
>
> or
>
> you could get my branch, set the version to whatever is comfortable for
> you and build your own Netty,
>
> My branch: https://github.com/guidomedina/netty/commits/3.10-SFS
>
> has the following milestone:
> https://github.com/netty/netty/issues?q=milestone%3A3.10.6.Final+is%3Aclosed
>
> plus some minor fixes I added myself, as of interest there is a race
> condition fixed at 3.10.6 and
> I saw another between 3.10.0 and 3.10.5 which might be causing the issue
> you are experiencing.
>
> HTH,
>
> Guido.
>
> --
> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] BoundedMailbox and pushTimeOut behavior

[Patrik Nordwall]

So it's this code we are talking about:

  def enqueue(receiver: ActorRef, handle: Envelope): Unit =
if (pushTimeOut.length >= 0) {

  if (!queue.offer(handle, pushTimeOut.length, pushTimeOut.unit))

receiver.asInstanceOf[InternalActorRef].provider.deadLetters.tell(

  DeadLetter(handle.message, handle.sender, receiver),
handle.sender)

} else queue put handle

That is offer with 0 timeout, that should not be blocking. Don't ask me
when queue.put is used.



On Fri, Apr 29, 2016 at 6:02 PM, Shannon Carey  wrote:

> Thanks Patrik.
>
> So you agree that setting timeout to 0 will block the sender when using a
> local receiver? Do you think I should contribute an update to the
> documentation?
>
> The code I'm working on has inherited Akka because it's based on another
> application, but my code is a Kafka consumer. So it is ok to block the
> "sender" (the kafka reader) if overall throughput is insufficient, allowing
> developers/auto-scaling time to improve the throughput until the Kafka
> checkpoint location falls off the horizon in Kafka. The actor graph is not
> complicated enough to worry about deadlock yet. Akka Streams definitely
> makes sense though, or possibly work pulling if it's simple to implement.
>
> Thanks again!
>
>
> On Friday, April 29, 2016 at 3:24:25 AM UTC-5, Patrik Nordwall wrote:
>>
>> Blocking the sender is a bad for scalability and can even result in
>> deadlocks or starvation if you aren't careful. It's also not location
>> transparent, i.e. it will not work for remote receiver.
>>
>> If you can't loose messages you should implement a resend-ack protocol
>> for at least once delivery, or make sure that the number of outstanding
>> messages are bounded with some kind of flow control, such as work pulling
>> pattern.
>>
>> It can also be good to consider Akka Streams, since it backpressure is
>> first class in the streams model.
>>
>> Regards,
>> Patrik
>>
>>
>>
>> On Sat, Apr 23, 2016 at 7:50 PM, Shannon Carey  wrote:
>>
>>> I'm a bit confused by the documentation vs. the source code when it
>>> comes to BoundedMailbox and pushTimeOut (aka "mailbox-push-timeout-time").
>>>
>>> The documentation (
>>> http://doc.akka.io/docs/akka/2.4.4/java/mailboxes.html) says,
>>> (implicitly regarding BoundedMailbox), "Other bounded mailbox
>>> implementations which will block the sender if the capacity is reached and
>>> configured with non-zero mailbox-push-timeout-time."
>>>
>>> It also says, (again about BoundedMailbox), "The following mailboxes
>>> should only be used with zero mailbox-push-timeout-time." but it does not
>>> say *why*.
>>>
>>> I found that in Mailboxes#lookupConfigurator(String), there's a warning
>>> when pushTimeOut > zero:
>>> "Configured potentially-blocking mailbox [$id] configured with non-zero
>>> pushTimeOut (${m.pushTimeOut}), which can lead to blocking behaviour when
>>> sending messages to this mailbox. Avoid this by setting
>>> `$id.mailbox-push-timeout-time` to `0`."
>>>
>>> This all implies that if pushTimeOut is zero, that there will be no
>>> blocking and therefore presumably if the mailbox is full the message will
>>> go immediately to dead letters.
>>>
>>> The reason I am confused by this is that BoundedMailbox
>>> uses BoundedMailbox.MessageQueue which is a LinkedBlockingQueue
>>> plus BoundedQueueBasedMessageQueue. If pushTimeOut >= 0,
>>> BoundedQueueBasedMessageQueue defines enqueue() as queue.put() which is
>>> blocking and doesn't send anything to dead letters (contrary to the
>>> documentation). What am I missing?
>>>
>>> What I would like is to guarantee that even if the consuming Actor is
>>> slow that no messages go to dead letters, and instead the producer is
>>> blocked while sending the message. If pushTimeOut=0 with a bounded mailbox
>>> is not the right way to do that, what is?
>>>
>>> Thanks!
>>> Shannon
>>>
>>> --
>>> >> 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 https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend  -  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 

Re: [akka-user] snapshot's sequence_nr is 0 for first time running

[Yan Pei]

Patric,

  The problem was gone if I send lots of messages.

  Thanks,
Yan

On Thursday, April 28, 2016 at 5:21:11 AM UTC-5, Patrik Nordwall wrote:
>
> what does your persistent actor look like?
>
> On Mon, Apr 25, 2016 at 7:23 PM, Yan Pei  
> wrote:
>
>> Got another issue.
>>
>> The logic is very simple: after sending certain number of messages, take 
>> a snapshot. But the sequence_nr is always 0 for the first time run. The 
>> second time, I saw some positive numbers in sequce_nr but the number is not 
>> what I am expecting.
>>
>>  persistence_id   | 
>> sequence_nr | ser_id | ser_manifest | snapshot | snapshot_data| 
>> timestamp
>>
>> --+-++--+--+--+---
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist0/$a0 | 
>> 120 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603958981
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist0/$a0 |   
>> 0 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603938737
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist1/$a1 | 
>> 120 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603958977
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist1/$a1 |   
>> 0 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603938737
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist2/$a2 | 
>> 120 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603958970
>>  mainaroraid1akka://ActorSystemmainaroraid1/user/persist2/$a2 |   
>> 0 |  1 |  | null | 0xaced0005740004736e6170 | 
>> 1461603938732
>>
>>
>>
>> What did I miss?
>>
>> Thanks very much!
>>
>> Yan
>>
>> -- 
>> >> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] BoundedMailbox and pushTimeOut behavior

[Shannon Carey]

Thanks Patrik.

So you agree that setting timeout to 0 will block the sender when using a 
local receiver? Do you think I should contribute an update to the 
documentation?

The code I'm working on has inherited Akka because it's based on another 
application, but my code is a Kafka consumer. So it is ok to block the 
"sender" (the kafka reader) if overall throughput is insufficient, allowing 
developers/auto-scaling time to improve the throughput until the Kafka 
checkpoint location falls off the horizon in Kafka. The actor graph is not 
complicated enough to worry about deadlock yet. Akka Streams definitely 
makes sense though, or possibly work pulling if it's simple to implement.

Thanks again!


On Friday, April 29, 2016 at 3:24:25 AM UTC-5, Patrik Nordwall wrote:
>
> Blocking the sender is a bad for scalability and can even result in 
> deadlocks or starvation if you aren't careful. It's also not location 
> transparent, i.e. it will not work for remote receiver.
>
> If you can't loose messages you should implement a resend-ack protocol for 
> at least once delivery, or make sure that the number of outstanding 
> messages are bounded with some kind of flow control, such as work pulling 
> pattern.
>
> It can also be good to consider Akka Streams, since it backpressure is 
> first class in the streams model.
>
> Regards,
> Patrik
>
>
>
> On Sat, Apr 23, 2016 at 7:50 PM, Shannon Carey  > wrote:
>
>> I'm a bit confused by the documentation vs. the source code when it comes 
>> to BoundedMailbox and pushTimeOut (aka "mailbox-push-timeout-time").
>>
>> The documentation (http://doc.akka.io/docs/akka/2.4.4/java/mailboxes.html) 
>> says, (implicitly regarding BoundedMailbox), "Other bounded mailbox 
>> implementations which will block the sender if the capacity is reached and 
>> configured with non-zero mailbox-push-timeout-time."
>>
>> It also says, (again about BoundedMailbox), "The following mailboxes 
>> should only be used with zero mailbox-push-timeout-time." but it does not 
>> say *why*.
>>
>> I found that in Mailboxes#lookupConfigurator(String), there's a warning 
>> when pushTimeOut > zero:
>> "Configured potentially-blocking mailbox [$id] configured with non-zero 
>> pushTimeOut (${m.pushTimeOut}), which can lead to blocking behaviour when 
>> sending messages to this mailbox. Avoid this by setting 
>> `$id.mailbox-push-timeout-time` to `0`."
>>
>> This all implies that if pushTimeOut is zero, that there will be no 
>> blocking and therefore presumably if the mailbox is full the message will 
>> go immediately to dead letters.
>>
>> The reason I am confused by this is that BoundedMailbox 
>> uses BoundedMailbox.MessageQueue which is a LinkedBlockingQueue 
>> plus BoundedQueueBasedMessageQueue. If pushTimeOut >= 0, 
>> BoundedQueueBasedMessageQueue defines enqueue() as queue.put() which is 
>> blocking and doesn't send anything to dead letters (contrary to the 
>> documentation). What am I missing?
>>
>> What I would like is to guarantee that even if the consuming Actor is 
>> slow that no messages go to dead letters, and instead the producer is 
>> blocked while sending the message. If pushTimeOut=0 with a bounded mailbox 
>> is not the right way to do that, what is?
>>
>> Thanks!
>> Shannon
>>
>> -- 
>> >> 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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Actor with stash

[Radi Radichev]

Hi,

I'm trying to create an UntupedActorWithStash in java, and for my use case 
I need to use a UnboundedPriorityMailbox. I have created my actor to extend 
UntypedActorWithUnrestrictedStash and implementing 
RequiresMessageQueue, I also create 
my actor with a dispatcher which has the PriorityMailbox as mailbox type. 
However every time I try to create my actor I get the error:

akka.actor.ActorInitializationException: DequeBasedMailbox required, got: 
akka.dispatch.UnboundedPriorityMailbox$MessageQueue

What am I missing here? I thought the UntypedActorWithUnrestrictedStash 
does not enforce a queue type?

Basically what I'm trying to achieve is:

I have an aggregator actor which broadcasts a message to a whole load of 
other actors and changes it's context to start to listen to replies from 
those other actors. The actor replies to the sender of the original message 
if all the replies are collected or if a scheduled timeout message is 
received. So my plan is to use the priority mailbox to set the timeout 
priority to higher than the other replies, and thus force the actor to 
either return all the replies or just the replies which it got when it 
received a timeout.

Any advice here?

Thanks,
Radi Radichev

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

[akka-user] Re: Surprising Akka Remoting behaviour: messages are delivered to (local) system with unresolvable hostname

['David Piggott' via Akka User List]

Thanks for the suggestion Guido. I had already looked at the Docker 
documentation for Akka remote configuration, but unfortunately it doesn't 
answer my question.

I should clarify at this point that although I was using Docker when I 
first noticed the behaviour in question, I then replicated it with a 
no-Docker cluster, before proceeding to isolate it to Akka Remoting. So the 
testcases I linked to are intended to be run directly on the machine you 
compile them on -- no Docker involved.

Cheers,
Dave


On Friday, 29 April 2016 11:23:06 UTC+1, Guido Medina wrote:
>
> Did you look at the Docker documentation for Akka remote configuration?
>
>
> http://doc.akka.io/docs/akka/current/java/remoting.html#Akka_behind_NAT_or_in_a_Docker_container
>
> HTH,
>
> Guido.
>

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

[akka-user] Self-healing system

[Tao Ma]

Hi everyone

I am a PhD student researching on self-healing system. Does anyone know 
some existing Akka applications that are fault tolerant and self-healing ?

Self-healing means the system can detect, isolate and recover faults within 
the system. 

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

[akka-user] Re: Surprising Akka Remoting behaviour: messages are delivered to (local) system with unresolvable hostname

[Guido Medina]

Did you look at the Docker documentation for Akka remote configuration?

http://doc.akka.io/docs/akka/current/java/remoting.html#Akka_behind_NAT_or_in_a_Docker_container

HTH,

Guido.

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

Re: [akka-user] BoundedMailbox and pushTimeOut behavior

[Patrik Nordwall]

Blocking the sender is a bad for scalability and can even result in
deadlocks or starvation if you aren't careful. It's also not location
transparent, i.e. it will not work for remote receiver.

If you can't loose messages you should implement a resend-ack protocol for
at least once delivery, or make sure that the number of outstanding
messages are bounded with some kind of flow control, such as work pulling
pattern.

It can also be good to consider Akka Streams, since it backpressure is
first class in the streams model.

Regards,
Patrik



On Sat, Apr 23, 2016 at 7:50 PM, Shannon Carey  wrote:

> I'm a bit confused by the documentation vs. the source code when it comes
> to BoundedMailbox and pushTimeOut (aka "mailbox-push-timeout-time").
>
> The documentation (http://doc.akka.io/docs/akka/2.4.4/java/mailboxes.html)
> says, (implicitly regarding BoundedMailbox), "Other bounded mailbox
> implementations which will block the sender if the capacity is reached and
> configured with non-zero mailbox-push-timeout-time."
>
> It also says, (again about BoundedMailbox), "The following mailboxes
> should only be used with zero mailbox-push-timeout-time." but it does not
> say *why*.
>
> I found that in Mailboxes#lookupConfigurator(String), there's a warning
> when pushTimeOut > zero:
> "Configured potentially-blocking mailbox [$id] configured with non-zero
> pushTimeOut (${m.pushTimeOut}), which can lead to blocking behaviour when
> sending messages to this mailbox. Avoid this by setting
> `$id.mailbox-push-timeout-time` to `0`."
>
> This all implies that if pushTimeOut is zero, that there will be no
> blocking and therefore presumably if the mailbox is full the message will
> go immediately to dead letters.
>
> The reason I am confused by this is that BoundedMailbox
> uses BoundedMailbox.MessageQueue which is a LinkedBlockingQueue
> plus BoundedQueueBasedMessageQueue. If pushTimeOut >= 0,
> BoundedQueueBasedMessageQueue defines enqueue() as queue.put() which is
> blocking and doesn't send anything to dead letters (contrary to the
> documentation). What am I missing?
>
> What I would like is to guarantee that even if the consuming Actor is slow
> that no messages go to dead letters, and instead the producer is blocked
> while sending the message. If pushTimeOut=0 with a bounded mailbox is not
> the right way to do that, what is?
>
> Thanks!
> Shannon
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Using materialized values from stages

[Durga Prasana]

Hi,

We're using akka-streams to process a stream of messages, which result in 
some actions.
Now, we need to find the number of messages being processed by the stream 
(well, not that plain vanilla, actually each message has a set of 
attributes, say, m_type, m_cmp, m_origin, ...).

One solution would be to have a counter in one of the stages that would 
keep track of that & update.
Other I'm hinted from the akka-docs could be the `M` materialized values of 
the stream (that we seldom use currently). However, I'm not so sure, how to 
start a runnable-graph once, & then keep on invoking the materialized value 
at each interval of let's say 5 mins (to kind of find messages processed so 
far) ?


We need the stream running continuously, so, doing a someGraph.run again 
and again doesn't make sense to find the materialized value at various 
intervals.
http://doc.akka.io/docs/akka/2.4.4/scala/stream/stream-quickstart.html#reactive-tweets

Would be thankful for some guidance here.

Thanks,
Durga

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

[akka-user] Surprising Akka Remoting behaviour: messages are delivered to (local) system with unresolvable hostname

['David Piggott' via Akka User List]

Hello,

I'll try not to spent too long on the background and to move quickly to the 
point. The background is that I was setting up a multi-node cluster, with 
each node running in its own Docker container. I had one seed node, and it 
was called "meter-seed". By that I mean that I had set 
akka.remote.netty.tcp.hostname to "meter-seed" and 
akka.remote.netty.tcp.bind-hostname to "0.0.0.0". Being a Docker Container, 
the hostname of the container itself was equal to the container ID, and 
would change from one instantiation of the image to the next. The non-seed 
node(s) joined the system fine because I gave them Dockers links named 
"meter-seed" -- so they could resolve the "meter-seed" hostname.

The bit that was surprising was when I realised that the seed itself had no 
way to resolve the hostname "meter-seed"; the seed container was identified 
only by its container ID. Why surprising? Because it was successfully 
joining the one configured seed node (itself): 
"akka.tcp://metering@meter-seed:2552". The fact it worked this way was 
actually useful, because it simplified the Docker configuration. But when I 
realised what was going on I asked myself the question: is this happening 
by accident or design? If it was the former (and so might change with a 
future Akka release), I'd need to change the Docker configuration to not 
rely on the Akka behaviour.

OK, background out of the way and on to the point: I did a little 
investigation and determined that the root cause is nothing specific to 
Akka Cluster -- it's in Akka Remoting.

It all comes down to the fact that I can configure Akka Remoting to listen 
on a hostname like "fakefakefake", and I'm then able to successfully send 
messages from one actor to another on the same node via an absolute path 
that contains the unresolvable hostname -- e.g. 
"akka.tcp://RemoteSystem@fakefakefake:2552/user/EchoActor".

I've put together a minimal test case to demonstrate this -- it's published 
here: https://gist.github.com/dhpiggott/a39c5b92a85c12e67b970ee49a1b4185.

The first test will fail because I'm asserting there that the observed 
behaviour should not happen.

I then stepped through that first test's execution with a breakpoint to 
trace the cause deeper within Akka Remoting. For ease of communication I've 
converted the observations I made while doing so into a second test that 
makes some assertions about Akka's internal state via reflection.

This second test will also fail because I'm again asserting there that some 
of the observed behaviour should not happen.

I did search for documentation that would confirm what the behaviour should 
actually be but couldn't find anything.

My question is simply this: is the observed behaviour as things are 
intended to be? I note on the one hand that the observed behaviour is 
potentially very useful, but on the other hand, it can also be quite 
surprising.

Cheers,
Dave

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