[akka-user] Enjoying Akka HTTP performance

[Adam]

Hi,

I'd just like to share my satisfaction from Akka HTTP performance in 2.4.10.
I'm diagnosing some low level Node.js performance issues and while running 
various tests that only require the most basic "Hello World" style code, I 
decided to take a few minutes to check how would Akka HTTP handle the same 
work.
I was quite impressed with the results, so I thought I'd share.

I'm running two c4.large instances (so two cores on each instance) - one 
running the HTTP service and another running wrk2.
I've tested only two short sets (seeing as I have other work to do):

   1. use 2 threads to simulate 100 concurrent users pushing 2k 
   requests/sec for 5 minutes
   2. use 2 threads to simulate 100 concurrent users pushing 20k 
   requests/sec for 5 minutes

In both cases, the tests are actually executed twice without a restart in 
between and I throw away the results of the first run.

The first run is just to get JIT and other adaptive mechanisms to do their 
thing.

5 minutes seems to be enough based on the CPU behavior I see, but for a 
more "official" test I'd probably use something longer.


As for the code, I was using vanilla Node code - the kind you see as the 
most basic example (no web frameworks or anything) but for Akka, I used the 
high level DSL.


Here's the Code:


*Akka HTTP*


package com.example.rest

import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.server.Directives._
import akka.stream.ActorMaterializer


case class Reply(message: String = "Hello World", userCount: Int)

object MyJsonProtocol
  extends akka.http.scaladsl.marshallers.sprayjson.SprayJsonSupport
with spray.json.DefaultJsonProtocol {

  implicit val replyFormat = jsonFormat2(Reply.apply)
}

object FullWebServer {
  var userCount = 0;

  def getReply() = {
userCount += 1
Reply(userCount=userCount)
  }

  def main(args: Array[String]) {
implicit val system = ActorSystem()
implicit val materializer = ActorMaterializer()
import MyJsonProtocol._

val route =
  get {
complete(getReply())
  }

// `route` will be implicitly converted to `Flow` using 
`RouteResult.route2HandlerFlow`
val bindingFuture = Http().bindAndHandle(route, "0.0.0.0", 3000)
println("Server online at http://127.0.0.1:3000/;)
  }
}


*Node*

var http = require('http');

let userCount = 0;
var server = http.createServer(function (request, response) {
userCount++;
response.writeHead(200, {"Content-Type": "application/json"});
const hello = {msg: "Hello world", userCount: userCount};
response.end(JSON.stringify(hello));
});

server.listen(3000);

console.log("Server running at http://127.0.0.1:3000/;);

(to be more exact there's also some wrapping code because I'm running this in a 
cluster so all cores can be utilized)


So for the first test, things are pretty much the same - Akka HTTP uses 
less CPU (4-6% vs. 10% in Node) and has a slightly lower average response 
time, but a higher max response time.

Not very interesting.


The second test was more one sided though.


The Node version maxed out the CPU and got the following results:


Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 215.794ms, rate sampling interval: 1623ms
  Thread calibration: mean lat.: 366.732ms, rate sampling interval: 1959ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 5.31s 4.48s   16.66s65.79%
Req/Sec 9.70k 0.87k   10.86k57.85%
  5806492 requests in 5.00m, 1.01GB read
Requests/sec:  19354.95
Transfer/sec:  3.43MB


Whereas for the Akka HTTP version I saw each core using ~40% CPU throughout 
the test and I had the following results:

Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 5.044ms, rate sampling interval: 10ms
  Thread calibration: mean lat.: 5.308ms, rate sampling interval: 10ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 1.83ms1.27ms  78.91ms   95.96%
Req/Sec10.55k 1.79k   28.22k75.98%
  5997552 requests in 5.00m, 1.00GB read
Requests/sec:  19991.72
Transfer/sec:  3.41MB


Which is not a huge increase over 2K requests/sec:


Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 1.565ms, rate sampling interval: 10ms
  Thread calibration: mean lat.: 1.557ms, rate sampling interval: 10ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 1.07ms  479.75us   8.09ms   62.57%
Req/Sec 1.06k   131.65 1.78k79.05%
  599804 requests in 5.00m, 101.77MB read
Requests/sec:   1999.33
Transfer/sec:347.39KB



In summary, I know this is far from a conclusive test, but I was still 
quite excited to see the results.

Keep up the good work!

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html

Re: [akka-user] Akka HTTP performance in 2.4.9

[Adam]

Thanks!

Adding -k indeed fixes this right away:

ab -k -c 400 -n 10 -m GET http://127.0.0.1:3000/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:akka-http/2.4.9
Server Hostname:127.0.0.1
Server Port:3000

Document Path:  /
Document Length:2 bytes

Concurrency Level:  400
Time taken for tests:   3.401 seconds
Complete requests:  10
Failed requests:0
Keep-Alive requests:10
Total transferred:  1670 bytes
HTML transferred:   20 bytes
Requests per second:29403.12 [#/sec] (mean)
Time per request:   13.604 [ms] (mean)
Time per request:   0.034 [ms] (mean, across all concurrent requests)
Transfer rate:  4795.23 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   2.8  0 509
Processing: 0   11  62.6  61566
Waiting:0   11  62.6  61566
Total:  0   11  62.8  61566

Percentage of the requests served within a certain time (ms)
  50%  6
  66%  8
  75%  8
  80%  9
  90% 13
  95% 16
  98% 26
  99% 32
 100%   1566 (longest request)


P.S.  - I wasn't familiar with wrk, but, of course, I realize running on 
the local machine is not really valid.
I only used this method to pick up on really basic issues (like this 
example of not using persistent connections illustrates perfectly)



On Tuesday, September 6, 2016 at 5:39:02 PM UTC+3, Konrad Malawski wrote:
>
> Without looking at the code, two things to fix right away in your 
> methodology:
>
> 1) You're running `ab` without persistent connections (also known as 
> "useless mode").
> Please run: `ab -k` to use keep-alive connections, which is what all http 
> clients and browsers do.
>
> 2) Please do not benchmark using the same host for running the app and 
> load generator...
> You're stealing resources from the http server as you're load generator is 
> trying to hit it as hard as it can, and the other way around.
> The benchmark will be completely skewed by that.
>
> ab is also not very good in general, use wrk instead - a more modern load 
> generator.
>
> -- 
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 6 September 2016 at 16:34:22, Adam (adam...@gmail.com ) 
> wrote:
>
> Hi,
>
> I've previously seen bad performance form Akka HTTP for a simple ping/pong 
> scenario (which I realize according to the release notes is still a 
> relatively bad scenario for Akka HTTP), but the results I'm getting are bad 
> enough that I'm wondering if my test is even valid.
>
> Here's my code:
>
> package com.example.rest
>
> import akka.NotUsed
> import akka.actor.ActorSystem
> import akka.http.scaladsl.Http
> import akka.http.scaladsl.model._
> import akka.stream.scaladsl.{Flow, Keep, RunnableGraph, Sink, Source}
> import akka.stream.{ActorMaterializer, ActorMaterializerSettings, Fusing}
>
> import scala.concurrent.Future
> import scala.io.StdIn
>
> object WebServer extends App {
>   implicit val system = ActorSystem()
>   implicit val materializer =  
> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>   implicit val executionContext = system.dispatcher
>
>   val response = HttpResponse(entity = 
> HttpEntity(ContentTypes.`text/plain(UTF-8)`,"Ok"))
>   val requestHandler: HttpRequest => HttpResponse = {
> case _ => response
>   }
>
>   val flow: Flow[HttpRequest, HttpResponse, NotUsed] = Flow[HttpRequest] map 
> requestHandler
>   val prefused = Fusing.aggressive(flow)
>   val httpHandler: Flow[HttpRequest, HttpResponse, NotUsed] = 
> Flow.fromGraph(prefused)
>
>   if (args(0) == "http"){
> runHttpServer()
>   } else {
> runPingPong(args(1).toInt)
>   }
>
>   def runHttpServer() = {
> val bindingFuture = Http().bindAndHandle(handler = httpHandler, interface 
> = "127.0.0.1  ", port = 3000)
>
> println("Type RETURN to exit")
> StdIn.readLine()
>
> bindingFuture
>   .flatMap(_.unbind()) // trigger unbinding from the port
>   .onComplete(_ => system.terminate())
>   }
>
>   def runPingPong(times: Int) = {
> va

[akka-user] Akka HTTP performance in 2.4.9

[Adam]

Hi,

I've previously seen bad performance form Akka HTTP for a simple ping/pong 
scenario (which I realize according to the release notes is still a 
relatively bad scenario for Akka HTTP), but the results I'm getting are bad 
enough that I'm wondering if my test is even valid.

Here's my code:

package com.example.rest

import akka.NotUsed
import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.model._
import akka.stream.scaladsl.{Flow, Keep, RunnableGraph, Sink, Source}
import akka.stream.{ActorMaterializer, ActorMaterializerSettings, Fusing}

import scala.concurrent.Future
import scala.io.StdIn

object WebServer extends App {
  implicit val system = ActorSystem()
  implicit val materializer =  
ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
  implicit val executionContext = system.dispatcher

  val response = HttpResponse(entity = 
HttpEntity(ContentTypes.`text/plain(UTF-8)`,"Ok"))
  val requestHandler: HttpRequest => HttpResponse = {
case _ => response
  }

  val flow: Flow[HttpRequest, HttpResponse, NotUsed] = Flow[HttpRequest] map 
requestHandler
  val prefused = Fusing.aggressive(flow)
  val httpHandler: Flow[HttpRequest, HttpResponse, NotUsed] = 
Flow.fromGraph(prefused)

  if (args(0) == "http"){
runHttpServer()
  } else {
runPingPong(args(1).toInt)
  }

  def runHttpServer() = {
val bindingFuture = Http().bindAndHandle(handler = httpHandler, interface = 
"127.0.0.1  ", port = 3000)

println("Type RETURN to exit")
StdIn.readLine()

bindingFuture
  .flatMap(_.unbind()) // trigger unbinding from the port
  .onComplete(_ => system.terminate())
  }

  def runPingPong(times: Int) = {
val ping = HttpRequest().withUri(Uri("/"))

val graph: RunnableGraph[Future[Int]] = Source(1 to times)
  .map(_ => ping)
  .via(httpHandler)
  .map(_ => 1)
  .toMat(Sink.fold[Int, Int](0)((a, b) => a + 1))(Keep.right)

val startTime = System.nanoTime()
val count: Future[Int] = graph.run()

count.onComplete(res => {
  if (res.isFailure) {
Console.err.println(s"failed with: ${res.failed}")
  } else {
println(s"ran for ${res.get} times")
val et = System.nanoTime() - startTime
val etMillis = et / 100.0
println(s"et: ${etMillis}ms")
  }
  system.terminate()
})
  }
}

The in memory scenario (runPingPong) yields the following results on my local 
windows machine:

ran for 10 times
et: 322.150515ms


Running ab to test actual local HTTP calls get me this:

ab -c 400 -n 10 -m GET http://127.0.0.1:3000/

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:akka-http/2.4.9
Server Hostname:127.0.0.1
Server Port:3000

Document Path:  /
Document Length:2 bytes

Concurrency Level:  400
Time taken for tests:   139.083 seconds
Complete requests:  10
Failed requests:0
Total transferred:  1620 bytes
HTML transferred:   20 bytes
Requests per second:719.00 [#/sec] (mean)
Time per request:   556.332 [ms] (mean)
Time per request:   1.391 [ms] (mean, across all concurrent requests)
Transfer rate:  113.75 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:01  24.7  0 593
Processing:13  552 394.65622144
Waiting:2  388 347.15261583
Total: 13  554 395.25622144

Percentage of the requests served within a certain time (ms)
  50%562
  66%586
  75%639
  80%   1047
  90%   1065
  95%   1096
  98%   1560
  99%   1574
 100%   2144 (longest request)


I was able to use the same approach with other frameworks (e.g. Play & 
Vertx) and got results which are much better.
I see in the 2.4.9 release notes that (on different hardware) 160K reqs/sec 
ping/pong requests were achieved, so what I'm seeing on my machine is 
really weird to me.
Is there something fundamentally wrong with my test above?
It would also be nice to see the code & configuration which was used to 
test 2.4.9's performance on EC2, if that's available somewhere.

Adam

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/curr

[akka-user] Re: Akka HTTP documentation about asynchronous completion of routes

[Adam]

Ultimately I was able to find a group of related directives.

So this for example works:

...

public Route route() {
 return parameterOptional("name", optName -> {
  String name = optName.orElse(_defaultName);
  return parameterOptional("times", optTimes -> {
   int times = optTimes.map(Integer::parseInt).orElse(1);
   final Marshaller<Saying, RequestEntity> marshaller = 
Jackson.marshaller();
   return completeOKWithFuture(futureSayHello(name, times), marshaller);
  });
 });
}

//convert the Observable to a completeionStage
public CompletionStage futureSayHello(final String name, final int 
times) {
...






On Monday, September 5, 2016 at 5:28:19 PM UTC+3, Adam wrote:
>
> Hi,
>
> I'm looking at the docs trying to find an example of how to create a route 
> that does not complete the result synchronously from the route tree, but 
> rather relies on some other asynchronous chain of events.
> All I can find is this page: 
> http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/routes.html
>
> That's not really enough to get started easily...
> Actually I think some of the methods mentioned there don't really exist.
> For example: Route::asyncHandler.
>
> Am I missing something here?
> Does a simple example exist and I simply can't find it?
> The activator code for Akka HTTP micro-service also seems to be out of 
> date, so I cannot use that either.
> I actually have some preexisting (POC grade) code that relied on 2.4.4 
> (unfortunately it was also hard to find what to do the first time around) 
> and I'm now converting it to 2.4.9 and yet it's still quite hard to easily 
> find what to do.
>
> Adam.
>

-- 
>>>>>>>>>>  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] Akka HTTP documentation about asynchronous completion of routes

[Adam]

Hi,

I'm looking at the docs trying to find an example of how to create a route 
that does not complete the result synchronously from the route tree, but 
rather relies on some other asynchronous chain of events.
All I can find is this page: 
http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/routes.html

That's not really enough to get started easily...
Actually I think some of the methods mentioned there don't really exist.
For example: Route::asyncHandler.

Am I missing something here?
Does a simple example exist and I simply can't find it?
The activator code for Akka HTTP micro-service also seems to be out of 
date, so I cannot use that either.
I actually have some preexisting (POC grade) code that relied on 2.4.4 
(unfortunately it was also hard to find what to do the first time around) 
and I'm now converting it to 2.4.9 and yet it's still quite hard to easily 
find what to do.

Adam.

-- 
>>>>>>>>>>  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: Akka HTTP performance for short lived connections

[Adam]

Small update - disabling auto fuse, or pre-fusing (with & without auto 
fusing) has an effect (BTW I could not find a way to do this with the java).
Performance is improved by up to 50%.

However, it's still not in the same order of magnitude as other libraries.
It's still at least 1 second for the fastest requests.

On Tuesday, April 19, 2016 at 12:25:24 AM UTC+3, Adam wrote:
>
> Yeah, no code is rather silly really...
>
> I've created this repository:
>
> https://github.com/adamhonen/Akka-Http-performance-test
>
> I didn't get a chance to try the suggestions above yet, though.
>
>
> On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>>
>> I see some results, but no code that is being benchmarked – please always 
>> post benchmarked code together with benchmark, otherwise it's hard to tell 
>> what's actually going on.
>>
>> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén <johan@typesafe.com> 
>> wrote:
>>
>>> Yet another thing to test could be to pre-fuse your Request => Response 
>>> flow, first, and then run that with autoFusing turned on or off. Locally I 
>>> get the best improvement with pre-fusing and no autoFusing. Looks like this:
>>>
>>>   implicit val materializer = 
>>> ActorMaterializer(ActorMaterializerSettings(system))
>>>
>>> val routes = 
>>>   path("benchmark") {
>>> get {
>>>   complete("ok")
>>> }
>>>   }
>>>
>>> val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
>>>
>>> val prefused = Fusing.aggressive(flow)
>>>
>>> Http().bindAndHandle(
>>>   handler = Flow.fromGraph(prefused),
>>>   interface = "localhost",
>>>   port = 9000)
>>>
>>> --
>>> John Andrén
>>> Akka Team, Lightbend Inc.
>>>
>>>
>>> On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>>>>
>>>> One thing that could be interesting to try out if you want to achieve 
>>>> as high throughput as possible where each new request is a new connection 
>>>> with the current akka-http version is to disable autoFusing (which is 
>>>> pretty costly). That can be done when you create the materializer like 
>>>> this: 
>>>>
>>>>   
>>>> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>>>>
>>>> This will of course come at the cost where persistent connections get a 
>>>> performance hit instead.
>>>>
>>>> --
>>>> John Andrén
>>>> Akka Team, Lightbend Inc.
>>>>  
>>>>
>>>> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>>>>
>>>>> Adam, thanks!
>>>>>
>>>>> Very informative. I also have found handy to use almost empty response 
>>>>> to estimate the whole request-response chain itself (starting from now 
>>>>> abandoned tiscaf [1] and rising rps up to almost 90K on humble 
>>>>> workstation 
>>>>> :) ).
>>>>>
>>>>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>>>>
>>>> -- 
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka HTTP performance for short lived connections

[Adam]

Yeah, no code is rather silly really...

I've created this repository:

https://github.com/adamhonen/Akka-Http-performance-test

I didn't get a chance to try the suggestions above yet, though.


On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>
> I see some results, but no code that is being benchmarked – please always 
> post benchmarked code together with benchmark, otherwise it's hard to tell 
> what's actually going on.
>
> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén <johan@typesafe.com 
> > wrote:
>
>> Yet another thing to test could be to pre-fuse your Request => Response 
>> flow, first, and then run that with autoFusing turned on or off. Locally I 
>> get the best improvement with pre-fusing and no autoFusing. Looks like this:
>>
>>   implicit val materializer = 
>> ActorMaterializer(ActorMaterializerSettings(system))
>>
>> val routes = 
>>   path("benchmark") {
>> get {
>>   complete("ok")
>> }
>>   }
>>
>> val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
>>
>> val prefused = Fusing.aggressive(flow)
>>
>> Http().bindAndHandle(
>>   handler = Flow.fromGraph(prefused),
>>   interface = "localhost",
>>   port = 9000)
>>
>> --
>> John Andrén
>> Akka Team, Lightbend Inc.
>>
>>
>> On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>>>
>>> One thing that could be interesting to try out if you want to achieve as 
>>> high throughput as possible where each new request is a new connection with 
>>> the current akka-http version is to disable autoFusing (which is pretty 
>>> costly). That can be done when you create the materializer like this: 
>>>
>>>   
>>> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>>>
>>> This will of course come at the cost where persistent connections get a 
>>> performance hit instead.
>>>
>>> --
>>> John Andrén
>>> Akka Team, Lightbend Inc.
>>>  
>>>
>>> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>>>
>>>> Adam, thanks!
>>>>
>>>> Very informative. I also have found handy to use almost empty response 
>>>> to estimate the whole request-response chain itself (starting from now 
>>>> abandoned tiscaf [1] and rising rps up to almost 90K on humble workstation 
>>>> :) ).
>>>>
>>>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>>>
>>> -- 
>> >>>>>>>>>> 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.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka HTTP performance for short lived connections

[Adam]

OK, thanks.

So just to be certain - in the meantime, is it expected that I'll see Akka HTTP 
perform ~100 times worse (or let's just say "much worse") than Play framework 
for such cases?

I was hoping it's actually something that I'm doing wrong because I was 
expecting it to be worse per the README, but still at the same order of 
magnitude.

-- 
>>  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] Rejections in Akka HTTP Java API

[Adam]

Hi,

I see Rejections are only described in the Scala version of the docs.
Is that on purpose?
What are my options using the Java API in order to customize rejections?

-- 
>>  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] Fusing in akka-streams 2.0

[Adam Warski]

> :-)
>
> But you are right, even though “semantics” didn’t change—for some suitable 
> definition—user expectations may still be violated. I’ll write up some docs 
> right away, it would be great if you could review them—I’ll ping you 
> (@adamw, right?).
>

Sure :) @adamw is the right handle

> A similar effect is when there are e.g. two computationally expensive, 
>> consecutive .map stages (they will now be processed sequentially, not 
>> concurrently), however with splits I think it was a very natural 
>> expectation that things will be processed in parallel.
>>
>>
>> Not necessarily. This is why the user gets to decide by declaring (some 
>> of) the branches as asynchronous.
>>
>
> Sure, though that's how I thought about broadcast, or merge. Maybe it's a 
> common misconception, but probably it's just me :)
>
>
> What we’re aiming for is absolutely homogenous rules, it would be strange 
> if some combinators worked differently than others. In this case that 
> implies that we’ll need to teach people about this rule, but that cannot be 
> avoided unless using magic—which is forbidden by rule #1 
> <http://www.google.com/url?q=http%3A%2F%2Fdoc.akka.io%2Fdocs%2Fakka-stream-and-http-experimental%2F2.0%2Fstream-design.html%23What_shall_users_of_Akka_Streams_expect_=D=1=AFQjCNGmbK7jHNEDN867ehdIKdrde0GaEQ>
> .
>

Right, I just need to switch from "implicit parallelism" to "explicit 
parallelism" :) 

> For linear flows, e.g.:
>
> Source(List(1, 2, 3))
>   .map(_ + 1)
>   .withAttributes(asyncBoundary) 
>   .map(_ * 2)
>   .to(Sink.ignore)
>
> here two actors will be created? First wrapping the Source & map(_ + 1), 
> second the map(_ * 2) & sink?
>
>
> Again correct  :-) Would you mind if I just used this example in the docs?
>

Sure, no problem :)

Thanks again!

Adam


-- 
>>>>>>>>>>  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] Fusing in akka-streams 2.0

[Adam Warski]

Hello,

I think that the new fusing support in akka-streams may have more 
consequences than I initially suspected. It quite drastically changes how 
concurrency is handled in akka-streams.

So far the model was quite clear: every stage gets materialised into an 
actor. If there's a split/broadcast, then all branches will be executed in 
parallel.

Now, with auto-fusing that changes. By default, if there's a split, the 
branches won't be executed in parallel. I think that's quite a big 
semantical change. A similar effect is when there are e.g. two 
computationally expensive, consecutive .map stages (they will now be 
processed sequentially, not concurrently), however with splits I think it 
was a very natural expectation that things will be processed in parallel.

Hence I have four questions:

1. if I have a split, where should the async boundary go? My first attempt 
was adding the async boundary attribute to the split graph stage itself, 
but that didn't work. By experimentation, I have to add it to the stages 
that are connected to the split's outputs.

2. how to insert async boundaries in linear pipelines? E.g.:

Source(List(1, 2, 3))
  .map(_ + 1) 
  .addAttributes(Attributes.asyncBoundary)
  .map(_ * 2)

doesn't compile

3. are you sure it's a good idea to make all processing stages fuseable by 
default? E.g. conflate seems to be naturally concurrent, as it deals with 
slower/faster components, which doesn't make much sense if everything is in 
one thread :)

4. which built-in stages are fuseable by default? The docs are quite vague 
here saying only "linear" ones. Which ones are these? 

If akka-streams now has *explicit* concurrency control, instead of the 
*implicit* one so far, maybe it would make sense to be explicit in the api 
(different name?) which stages will run concurrently by default?

Thanks,
Adam

-- 
>>>>>>>>>>  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] Fusing in akka-streams 2.0

[Adam Warski]

>
>
> Now, with auto-fusing that changes. By default, if there's a split, the 
> branches won't be executed in parallel. I think that's quite a big 
> semantical change.
>
>
> This is a bit of an overstatement: the semantics of the stream processing 
> do not change, the same rules apply to how elements flow and how 
> back-pressure is handled, all branches of a broadcast will make progress 
> concurrently—but not necessarily in parallel. This means that the 
> management of resource allocation has changed, not the semantics.
>

Right, my wording was bad, though what the end-user observes could be quite 
different. I couldn't find the right words, but changing the default stream 
behaviour from "parallel" to "concurrent" describes it correctly I guess? 
(which then, at some level, can be viewed as different semantics ;) )

Probably also the fact that in my oversimplified tests I use Thread.sleep 
for simulating "work" plays a role ;)
 

> A similar effect is when there are e.g. two computationally expensive, 
> consecutive .map stages (they will now be processed sequentially, not 
> concurrently), however with splits I think it was a very natural 
> expectation that things will be processed in parallel.
>
>
> Not necessarily. This is why the user gets to decide by declaring (some 
> of) the branches as asynchronous.
>

Sure, though that's how I thought about broadcast, or merge. Maybe it's a 
common misconception, but probably it's just me :)
 

> Hence I have four questions:
>
> 1. if I have a split, where should the async boundary go? My first attempt 
> was adding the async boundary attribute to the split graph stage itself, 
> but that didn't work. By experimentation, I have to add it to the stages 
> that are connected to the split's outputs.
>
>
> I realize that in the final release frenzy we forgot to add documentation 
> on how this actually works, I apologize. In short, adding attributes 
> applies to the whole graph on which they are added, and adding an 
> asynchronous boundary adds that boundary around the graph that has 
> previously been constructed. This means that the right place is around the 
> flow that gets attached to the split’s outputs. Currently that looks like
>
> someFlow.via(Flow[...]. here>.withAttributes(Attributes.asyncBoundary))
>
> which will run  in one extra actor.
>

so if I have a split component, and I want branches to be run in parallel 
(different actors), I need to do:

val branch1 = someFlow.withAttributes(asyncBoundary)
val branch2 = someFlow.withAttributes(asyncBoundary) 

split.out1 ~> branch1
split.out2 ~> branch2

Correct?

For linear flows, e.g.:

Source(List(1, 2, 3))
  .map(_ + 1)
  .withAttributes(asyncBoundary) 
  .map(_ * 2)
  .to(Sink.ignore)

here two actors will be created? First wrapping the Source & map(_ + 1), 
second the map(_ * 2) & sink?

>
> 2. how to insert async boundaries in linear pipelines? E.g.:
>
> Source(List(1, 2, 3))
>   .map(_ + 1) 
>   .addAttributes(Attributes.asyncBoundary)
>
>
> This is an oversight, we’ll need to provide appropriate overrides of this 
> method in all subclasses (ticket 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fakka%2Fakka%2Fissues%2F19261=D=1=AFQjCNEfY1IhROusDQU4j0f_TYmsIpCA_Q>
>  created).
>

Thx :)

> 3. are you sure it's a good idea to make all processing stages fuseable by 
> default? E.g. conflate seems to be naturally concurrent, as it deals with 
> slower/faster components, which doesn't make much sense if everything is in 
> one thread :)
>
>
> This is a misconception: conflate is not concurrent, it is aware of 
> back-pressure, and it works even better when fused because that removes 
> additional (implicit) buffers that can lead to rather surprising behavior. 
> All operations should be fusable, but I agree that the fusing algorithm 
> should become more intelligent in selecting which parts of a graph to 
> fuse—right now it is called “Fusing.aggressive” because it will fuse 
> everything it can.
>

True about the buffers, took me a while to understand one example ;) Having 
conflate only makes sense if there's some non-fused component out there I 
guess, but you are correct of course that it can be fused with things 
before/after it. 

> 4. which built-in stages are fuseable by default? The docs are quite vague 
> here saying only "linear" ones. Which ones are these? 
>
>
> It is easier to name the exceptions: SslTlsStage, groupBy, and some 
> sources and sinks (but for those the difference is typically not that 
> large).
>

 Ah, ok, well I still think it might be a good idea to explicitly mark them 
as non-fuseable at least in the docs. Once you have to think about where to 
pu

Re: [akka-user] Fusing in akka-streams 2.0

[Adam Warski]

On Tuesday, December 22, 2015 at 5:17:09 PM UTC+1, Konrad Malawski wrote:
>
>
> I'll leave the semantics questions to Roland or Endre to tackle (in 
> general it should not change semantics), but a few quick ones:
>
>
> 2. how to insert async boundaries in linear pipelines? E.g.:
>
> Source(List(1, 2, 3))
>   .map(_ + 1) 
>   .addAttributes(Attributes.asyncBoundary)
>   .map(_ * 2)
>
> doesn't compile
>
> Source(List(1,2,3)).map(identity).withAttributes(Attributes.asyncBoundary).map(identity)
>
> Docs about it will come soon.
>

Thanks! :) I guess the addAttributes variant could be hidden.

 

> 4. which built-in stages are fuseable by default? The docs are quite vague 
> here saying only "linear" ones. Which ones are these? 
>
> Where is that stated? That's outdated info.
>
> Almost all default stages are (except TLS Stage and very specialised 
> ones), that's explained here: (in the docs) 
> https://github.com/akka/akka/commit/f613ef17e25a9e6b005edae925cc1ff75cf87ae9
>

I've read this: 
http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0/scala/migration-guide-1.0-2.x-scala.html,
 
linked from the blog.
This says that:

"Fusable elements are
* all GraphStages (this includes all built-in junctions apart from groupBy)
* all Stages (this includes all built-in linear operators)"

though I'm not sure which elements are linear, stages or graph stages (from 
the available API)

Thanks,
Adam

-- 
>>>>>>>>>>  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: OutOfMemoryError due to too much logging

[Adam]

Hi,

I've read it in the past, but was hoping it's not accurate (I'm already 
using an asynchronous logger as the backend).
It basically says that no - there is no way to achieve what I want with 
Akka Logging, because while an asynchronous backend may help, the messages 
still go through some sort of unbounded queue.
So in the case of a fast producer (lots of logging requests) and a slow 
consumer (logging backend reading from this queue), you will still get an 
OutOfMemoryError.

OK, so I guess I'll just use those loggers directly and I'll have to 
populate the MDC on my own.
Probably not that much work anyway.

Thanks!

On Monday, December 14, 2015 at 10:53:13 AM UTC+2, Johan Andrén wrote:
>
> Hi Adam,
>
> I think what you are describing is covered in the logging docs: 
> http://doc.akka.io/docs/akka/2.4.1/scala/logging.html#Loggers and 
> http://doc.akka.io/docs/akka/2.4.1/java/logging.html#Loggers
>
> It could probably be more clear though, but the system behaving bad with 
> high logging load and configuring an async appender and dropping DEBUG and 
> INFO messages on high load is mentioned.
>
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
>
> On Sunday, December 13, 2015 at 5:15:36 PM UTC+1, Adam wrote:
>>
>> Hi,
>>
>> I sometimes see this issue where I want to switch logs to DEBUG, but due 
>> to the large number of messages the JVM will crash on OutOfMemory which 
>> turns out to be due to the accumulation of logging events.
>> Most logging frameworks have the ability to drop messages beyond a 
>> certain number and so do Akka unbounded mailboxes.
>>
>> Is there a way to achieve this with Akka logging as well?
>> The behavior of the non blocking unbounded mailbox is what I have in mind 
>> (logging frameworks usually add a warning of some kind telling you that 
>> messages are being dropped, but I can manage without this for now).
>>
>> Alternatively, I could just using my logger directly.
>> It's asynchronous anyway. The only issue with that is that I find the 
>> extra MDC data of actor path very useful when looking at piles of DEBUG 
>> logs.
>> It makes zeroing in on a single transaction very simple.
>>
>

-- 
>>>>>>>>>>  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] OutOfMemoryError due to too much logging

[Adam]

Hi,

I sometimes see this issue where I want to switch logs to DEBUG, but due to 
the large number of messages the JVM will crash on OutOfMemory which turns 
out to be due to the accumulation of logging events.
Most logging frameworks have the ability to drop messages beyond a certain 
number and so do Akka unbounded mailboxes.

Is there a way to achieve this with Akka logging as well?
The behavior of the non blocking unbounded mailbox is what I have in mind 
(logging frameworks usually add a warning of some kind telling you that 
messages are being dropped, but I can manage without this for now).

Alternatively, I could just using my logger directly.
It's asynchronous anyway. The only issue with that is that I find the extra 
MDC data of actor path very useful when looking at piles of DEBUG logs.
It makes zeroing in on a single transaction very simple.

-- 
>>  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: Akka persistence query examples

[Adam Dohnal]

Hello,

now I better understand queries like allPersistenceIds() and 
eventsByPersistenceId(persistenceId). What can I do if persistent query 
implementation I use does not support live stream of events? Should I 
implement polling myself (schedule message to self and after receive call 
query again)? But every time this query will be called, every event will be 
processed again and again. Should I store somewhere lastProcessedEventNr 
and use it as offset in eventsByPersistenceId?

-- 
>>  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] ActorSelection vs ActorRef

[Adam]

But that is not really accurate, isn't it?

When restarted the ActorRef is still perfectly valid and you only need to watch 
actors in case you have reason to believe that they will be terminated. Also, 
messages don't get lost during the restart, because the mailbox isn't restarted 
(well messages can always get "lost". I mean the great majority of them)

Am I wrong?
If I am, my system has been magically staying up through all sorts of issues 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-http] akka-http-session project: client-side sessions, remember me, csrf

[Adam Warski]

Hello,

Without steering you off your current path, I just wish to mention JWT 
> (Json Web Token) which is a token forma <http://jwt.io>t typically sent 
> as a OAuth2 Bearer Token (using the HTTP Authorization header). JWT has 
> security considerations as well as a client side singed session (claims) 
> addressed in a standardized way with support for both symmetrical and 
> asymmetrical signature and encryptions. 
>

that's quite an old thread, but just for reference I wanted to mention that 
I just released v0.2 of akka-http-session 
(https://github.com/softwaremill/akka-http-session) which contains some 
basic support for JWT - sessions can be now transported using headers 
(instead of cookies), and encoded in the specified json-based format.

Adam 

-- 
>>>>>>>>>>  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] Akka persistence query examples

[Adam Dohnal]

Hello,

recently I read through new akka-persistence-query-experimental module and 
would like to see some tutorials and examples to see how it can work. 
Documentation is really abstract for me. Unfortunately, I'm not able to 
find any activator templates nor tutorials. 

What I understand is how can I get a stream of events for my aggregate 
root. But how can I construct my read model. Should I subscribe to that 
event stream and for each event I should update ma read model and store it 
to read database? I think I am little confused.

Can you guys share your experience with that module? Some blog posts, 
mini-projects on github etc... to show how can it be used to implement 
query side of CQRS? Thank you

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Event-sourcing with aka-persistence

[Adam Dohnal]

Yes, you are right that these events should be persisted atomically

Dne neděle 25. října 2015 0:25:02 UTC+2 Michael Omann napsal(a):
>
> You can (and should) avoid this by emitting 2 events during command 
> handling instead if one.
>
> So instead of :
>
> AddExperience(10) -> ExperienceAdded(10) -> EarnLevel(1) -> LevelEarned(1)
>
> your should derive both Events from your player's state and atomically 
> persist 2 Events using persistAll(...)
>
> AddExperience(10) -> Seq(ExperienceAdded(10), LevelEarned(1))
>
>
> It fundamental that those events are stored atomically (either both or no 
> at all), otherwise your players state could be corrupted. Imagine the first 
> event (ExperienceAdded(10)) is saved successfully while  LevelEarned(10)fails 
> to persist properly. During recovery your player would end up in an 
> inconsistent state. Those two events must be stored in a single write 
> operation.
>
>
>
>
> I also believe that using an observable member inside an actor breaks the 
> actor model. Events received in the subscribe callback (e.g. onNext()) are 
> bypassing the mailbox, adding an additional inlet to the actor. That leads 
> to many problems, shared mutable state and multithreading inside the actor 
> to name just two. I may be wrong. Maybe Patrik can comment on that.
>
>
> Mike
>
>
>
> On Tuesday, October 20, 2015 at 8:32:50 AM UTC+2, Adam Dohnal wrote:
>>
>> You understand it right. Unfortunately, your solution won't work. Suppose 
>> player has 30/100 health (current/max) and 99/100 experience and two 
>> messages are sent to him with this order:
>>
>> AddExperience(10)
>> TakeDamage(40)
>>
>> Correct behaviour is that first 10 xp is added to 109/100 ... level is 
>> earned which cause to gain full hp 100/100. Only after then TakeDamage can 
>> by applied which causes to change player's hp to 60/100.
>>
>> If you would send LevelEarned to self, it will be processed after 
>> TakeDamage message and player will die.
>>
>> I would like to process each command at the time and persist ALL its 
>> consequence. Problem is that my consequences are found asynchronously :(
>>
>> Dne pondělí 19. října 2015 12:15:33 UTC+2 Patrik Nordwall napsal(a):
>>>
>>> If I understand it correctly your question is about how to persist the 
>>> LevelEarned event which comes via the 
>>> asyncrounous player.observable.subscribe callback. Since this is an actor 
>>> you must turn that callback into a message that is sent to self and when 
>>> receiving that message you can persist it.
>>>
>>> /Patrik
>>>
>>> On Mon, Oct 12, 2015 at 3:17 PM, Adam Dohnal <dohna...@gmail.com> wrote:
>>>
>>>> Hello, 
>>>>
>>>> I am new in Akka and I am trying to develop some mini project to test 
>>>> some things (akka, rx, cqrs, es etc..)
>>>>
>>>> I think I understand the concept of cqrs/es and how it fit to akka. My 
>>>> problem is probably more theoretical than technical.
>>>>
>>>> Let's say, I have class Player, which has several Attribute[T] 
>>>> attributes ... these attributes can be for example player's current 
>>>> health, 
>>>> vitality, experience, level etc ... These attributes have dependencies ... 
>>>> for example currentHealth is defined as 10 * vitality ... if experience is 
>>>> > 100 new level is earns, which causes to add 1 vitality, which causes to 
>>>> add 10 health ... Hopefully, you get the point.
>>>>
>>>> I like the idea to implement this using reactive streams. Each 
>>>> Attribute[T] should be considered as Observable[T] and with all these 
>>>> excellent operators I can model dependencies I have described before.
>>>>
>>>> Now I am trying to model each Player as actor, which can handle 
>>>> commands (AddExperience(...), AddVitality(...) etc...) and produce events 
>>>> (ExperienceAdded(...), LevelEarned(...)) which should be event sourced.
>>>>
>>>> Problem is, that when I am handling command I directly don't know what 
>>>> events should be generated ... for example AddExperience(100) is handled 
>>>> and after some validation ExperienceAdded(100) should be persisted to 
>>>> event 
>>>> store. When it success, it should be applied to my domain, which emit 
>>>> value 
>>>> change in that attribute observable and new level can be earned ... but 
>>>> how 
>>>> can I persist tha

Re: [akka-user] Modeling synchronous startup behavior

[Adam]

Hi,

In my system I have an initialization sequence that must take place at a 
certain order.
Basically I don't want to open my system for incoming requests, before all 
services are properly started.
So what I needed is sort of similar to what you describe here.

I've implemented it without ask.
Whenever a "service" actor is started it starts initialization in preStart 
and ultimately sends a ServiceStarted back to it's parent.
As I sometimes have a hierarchy of such services, some of them do not 
immediately reply from preStart as they themselves wait for of their 
dependencies to reply with ServiceStarted.
During this sequence I have a receive timeout set in the waiting Actors and 
I remove it once they are fully initialized.

In my case this all takes place within the same JVM, so I didn't bother 
with Acks, so overall it's not too complex.

I hope this helps.



On Monday, October 19, 2015 at 6:16:51 PM UTC+3, Rich Henry wrote:
>
> All the other components are thread-safe.
>
> I just need an order of operations including the actorOf call, so coming 
> full circle, my original plan was to use some kind of initialization 
> message with the ask pattern to sync it up.
>
> I was trying to figure out if this is the best i can do.
>
>
>
>
> On Monday, October 19, 2015 at 11:00:58 AM UTC-4, √ wrote:
>>
>> Hi Rich,
>>
>> On Mon, Oct 19, 2015 at 4:50 PM, Rich Henry  wrote:
>>
>>> I would if it told me when that chain of events starts and stops 
>>> relative to the actorOf call itself.
>>>
>>
>> actorOf is asynchronous so that's completely separate from the lifecycle.
>>  
>>
>>>
>>> My actor needs to register with another non-actor subsystem before i 
>>> interact with it, so If i write code like...
>>>
>>> val subsys = new SubSys()
>>> val a = system.actorOf(Props(classOf[MyActor], subsys)) // constructor 
>>> registers with subsys
>>> subsys.go()
>>>
>>> There is a race condition as the constructor for my actor doesn't get 
>>> called before .go(). 
>>>
>>
>> Is `subsys` threadsafe? Can your MyActor send a message somewhere to 
>> indicate that it has registered with subsys?
>>  
>>
>>>
>>>
>>> On Monday, October 19, 2015 at 10:24:32 AM UTC-4, √ wrote:
>>>


 On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  wrote:

> I guess that's the why of question 2. Im not clear when the different 
> lifecycle phases, like preStart, occur. 
>
> I would assume preStart occurs after object construction, and is 
> asynchronous to the system call used to create the actor, is that not so?
>
>
 Does the documentation help?

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

  

> On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>>
>> Hi Rich,
>>
>> and why can't it be executed in preStart()?
>>
>> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  
>> wrote:
>>
>>> I had seen a previous post that didn't really seem to come to any 
>>> definite conclusion about this subject.
>>>
>>> I have some synchronous behavior I need to accomplish during my 
>>> actor's construction, but the constructor is called asynchronously.
>>>
>>> 1) Is the accepted way to do this to use an initialization message 
>>> of some kind with the ask pattern?
>>>
>>> 2) Is there any documentation beyond the short section in the manual 
>>> that talks about actor lifecycle specifics?
>>>
>>> -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> √
>>
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: 
> https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google 
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to akka-user+...@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 

Re: [akka-user] Event-sourcing with aka-persistence

[Adam Dohnal]

Interesting idea, thanks. But i'm afraid I will not recognise when my event 
stream is finished. I will try to think about it and redesign it to get an 
Observable which will be finite. 

If I succeed at it, I can simply convert that finite Observable to 
collection and persist that events

But thank you for your thoughts.

Dne úterý 20. října 2015 10:41:32 UTC+2 Patrik Nordwall napsal(a):
>
>
>
> On Tue, Oct 20, 2015 at 8:26 AM, Adam Dohnal <dohna...@gmail.com 
> > wrote:
>
>> You understand it right. Unfortunately, your solution won't work. Suppose 
>> player has 30/100 health (current/max) and 99/100 experience and two 
>> messages are sent to him with this order:
>>
>> AddExperience(10)
>> TakeDamage(40)
>>
>> Correct behaviour is that first 10 xp is added to 109/100 ... level is 
>> earned which cause to gain full hp 100/100. Only after then TakeDamage can 
>> by applied which causes to change player's hp to 60/100.
>>
>> If you would send LevelEarned to self, it will be processed after 
>> TakeDamage message and player will die.
>>
>> I would like to process each command at the time and persist ALL its 
>> consequence. Problem is that my consequences are found asynchronously :(
>>
>
> Then you need to stash all incoming commands until you are done with all 
> events.
>  
>
>>
>> Dne pondělí 19. října 2015 12:15:33 UTC+2 Patrik Nordwall napsal(a):
>>>
>>> If I understand it correctly your question is about how to persist the 
>>> LevelEarned event which comes via the 
>>> asyncrounous player.observable.subscribe callback. Since this is an actor 
>>> you must turn that callback into a message that is sent to self and when 
>>> receiving that message you can persist it.
>>>
>>> /Patrik
>>>
>>> On Mon, Oct 12, 2015 at 3:17 PM, Adam Dohnal <dohna...@gmail.com> wrote:
>>>
>>>> Hello, 
>>>>
>>>> I am new in Akka and I am trying to develop some mini project to test 
>>>> some things (akka, rx, cqrs, es etc..)
>>>>
>>>> I think I understand the concept of cqrs/es and how it fit to akka. My 
>>>> problem is probably more theoretical than technical.
>>>>
>>>> Let's say, I have class Player, which has several Attribute[T] 
>>>> attributes ... these attributes can be for example player's current 
>>>> health, 
>>>> vitality, experience, level etc ... These attributes have dependencies ... 
>>>> for example currentHealth is defined as 10 * vitality ... if experience is 
>>>> > 100 new level is earns, which causes to add 1 vitality, which causes to 
>>>> add 10 health ... Hopefully, you get the point.
>>>>
>>>> I like the idea to implement this using reactive streams. Each 
>>>> Attribute[T] should be considered as Observable[T] and with all these 
>>>> excellent operators I can model dependencies I have described before.
>>>>
>>>> Now I am trying to model each Player as actor, which can handle 
>>>> commands (AddExperience(...), AddVitality(...) etc...) and produce events 
>>>> (ExperienceAdded(...), LevelEarned(...)) which should be event sourced.
>>>>
>>>> Problem is, that when I am handling command I directly don't know what 
>>>> events should be generated ... for example AddExperience(100) is handled 
>>>> and after some validation ExperienceAdded(100) should be persisted to 
>>>> event 
>>>> store. When it success, it should be applied to my domain, which emit 
>>>> value 
>>>> change in that attribute observable and new level can be earned ... but 
>>>> how 
>>>> can I persist that event?
>>>>
>>>> I try to write some pseudo-code
>>>>
>>>> class ExamplePersistentActor extends PersistentActor {
>>>>   val Player player = ... // domain
>>>>
>>>>   val subscription = player.observable.subscribe {
>>>> // here I get asynchronously information about that level is increased 
>>>> ... should I call persist here?
>>>> }
>>>>
>>>> val receiveCommand: Receive = {
>>>> case AddExperience(xp: Int) => {
>>>>  persist(ExperienceAdded(xp)) { event =>
>>>>   player.addExperience(xp) // should produce LevelEarned(1) event, 
>>>> which should be also persisted
>>>> }   
>>>>   }
>>>> }
>>>>
>>>> So I have reference to Play

Re: [akka-user] Event-sourcing with aka-persistence

[Adam Dohnal]

You understand it right. Unfortunately, your solution won't work. Suppose 
player has 30/100 health (current/max) and 99/100 experience and two 
messages are sent to him with this order:

AddExperience(10)
TakeDamage(40)

Correct behaviour is that first 10 xp is added to 109/100 ... level is 
earned which cause to gain full hp 100/100. Only after then TakeDamage can 
by applied which causes to change player's hp to 60/100.

If you would send LevelEarned to self, it will be processed after 
TakeDamage message and player will die.

I would like to process each command at the time and persist ALL its 
consequence. Problem is that my consequences are found asynchronously :(

Dne pondělí 19. října 2015 12:15:33 UTC+2 Patrik Nordwall napsal(a):
>
> If I understand it correctly your question is about how to persist the 
> LevelEarned event which comes via the 
> asyncrounous player.observable.subscribe callback. Since this is an actor 
> you must turn that callback into a message that is sent to self and when 
> receiving that message you can persist it.
>
> /Patrik
>
> On Mon, Oct 12, 2015 at 3:17 PM, Adam Dohnal <dohna...@gmail.com 
> > wrote:
>
>> Hello, 
>>
>> I am new in Akka and I am trying to develop some mini project to test 
>> some things (akka, rx, cqrs, es etc..)
>>
>> I think I understand the concept of cqrs/es and how it fit to akka. My 
>> problem is probably more theoretical than technical.
>>
>> Let's say, I have class Player, which has several Attribute[T] attributes 
>> ... these attributes can be for example player's current health, vitality, 
>> experience, level etc ... These attributes have dependencies ... for 
>> example currentHealth is defined as 10 * vitality ... if experience is > 
>> 100 new level is earns, which causes to add 1 vitality, which causes to add 
>> 10 health ... Hopefully, you get the point.
>>
>> I like the idea to implement this using reactive streams. Each 
>> Attribute[T] should be considered as Observable[T] and with all these 
>> excellent operators I can model dependencies I have described before.
>>
>> Now I am trying to model each Player as actor, which can handle commands 
>> (AddExperience(...), AddVitality(...) etc...) and produce events 
>> (ExperienceAdded(...), LevelEarned(...)) which should be event sourced.
>>
>> Problem is, that when I am handling command I directly don't know what 
>> events should be generated ... for example AddExperience(100) is handled 
>> and after some validation ExperienceAdded(100) should be persisted to event 
>> store. When it success, it should be applied to my domain, which emit value 
>> change in that attribute observable and new level can be earned ... but how 
>> can I persist that event?
>>
>> I try to write some pseudo-code
>>
>> class ExamplePersistentActor extends PersistentActor {
>>   val Player player = ... // domain
>>
>>   val subscription = player.observable.subscribe {
>> // here I get asynchronously information about that level is increased 
>> ... should I call persist here?
>> }
>>
>> val receiveCommand: Receive = {
>> case AddExperience(xp: Int) => {
>>  persist(ExperienceAdded(xp)) { event =>
>>   player.addExperience(xp) // should produce LevelEarned(1) event, which 
>> should be also persisted
>> }   
>>   }
>> }
>>
>> So I have reference to Player which has observable of all events that are 
>> produced ... but I don't how to persist them :/
>>
>> -- 
>> >>>>>>>>>> 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 <http://typesafe.com/> -  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] Re: Behavior of Akka when you sleep in an actor

[Adam]

I don't understand the purpose of "keeping the actor busy".
Why not use the actor system's scheduler in order to implement the delay?

Do you actually want to use CPU or other resources?

The only thing to pay attention to is that the scheduler, has a certain 
precision, so the delay may turn out to be slightly larger than aimed for.

For testing purposes, BTW, depending on the situation, I sometimes use a count 
down latch instead of timed delays. When possible, it makes the tests much 
faster to execute.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[Adam]

 

Hi,

 

I like most of the described changes.

Here are my personal reservations:

 

1. I prefer a single method name with many overloads over many method names 
that say what are the arguments.

 

2. I think the usage of from in two places (e.g. BidiFlow.fromXYZ and 
Builder.from(...), might be confusing. 

The latter makes a lot of sense, so the former can be renamed to something 
else. Being more used to RxJava\RxScala, I kind of like “of” which is very 
succinct and intuitive.

Of course BidiFlow is just an example, in the list of renames there are 
lots of fromXYZ methodz. I would replace them all with “of”.

This way when you need to create something, you always know to look for an 
“of” method, or whatever consistent name you pick (this sort of works in 
conjunction with my first comment).

 

3. I think loosing addEdge will make it harder for new comers to learn the 
DSL, which is already not trivial (at least in my eyes as  compare it to 
RxJava\RxScala).

Usually having less options can make things simpler, but in this case I 
know I’ve used the addEdge method in order to try and make sense of how to 
use the Akka streams DSL.

Adam
On Saturday, October 17, 2015 at 11:57:25 PM UTC+3, √ wrote:
>
> Hi everyone,
>
> I'm proposing the following (breaking) changes to the FlowGraph-related 
> APIs, in order to make it consistent, with a smaller surface area and with 
> more obvious demarcation of power-level for "dropping down to"/"tapping 
> into" FlowGraph-mode.
>
> Most, if not all, of the migration can be mechanically applied (I know 
> because I did it in the codebase).
>
> See the PR for details: https://github.com/akka/akka/pull/18700
>
> -- 
> Cheers,
> √
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Event-sourcing with aka-persistence

[Adam Dohnal]

Hello, 

I am new in Akka and I am trying to develop some mini project to test some 
things (akka, rx, cqrs, es etc..)

I think I understand the concept of cqrs/es and how it fit to akka. My 
problem is probably more theoretical than technical.

Let's say, I have class Player, which has several Attribute[T] attributes 
... these attributes can be for example player's current health, vitality, 
experience, level etc ... These attributes have dependencies ... for 
example currentHealth is defined as 10 * vitality ... if experience is > 
100 new level is earns, which causes to add 1 vitality, which causes to add 
10 health ... Hopefully, you get the point.

I like the idea to implement this using reactive streams. Each Attribute[T] 
should be considered as Observable[T] and with all these excellent 
operators I can model dependencies I have described before.

Now I am trying to model each Player as actor, which can handle commands 
(AddExperience(...), AddVitality(...) etc...) and produce events 
(ExperienceAdded(...), LevelEarned(...)) which should be event sourced.

Problem is, that when I am handling command I directly don't know what 
events should be generated ... for example AddExperience(100) is handled 
and after some validation ExperienceAdded(100) should be persisted to event 
store. When it success, it should be applied to my domain, which emit value 
change in that attribute observable and new level can be earned ... but how 
can I persist that event?

I try to write some pseudo-code

class ExamplePersistentActor extends PersistentActor {
  val Player player = ... // domain

  val subscription = player.observable.subscribe {
// here I get asynchronously information about that level is increased ... 
should I call persist here?
}

val receiveCommand: Receive = {
case AddExperience(xp: Int) => {
 persist(ExperienceAdded(xp)) { event =>
  player.addExperience(xp) // should produce LevelEarned(1) event, which 
should be also persisted
}   
  }
}

So I have reference to Player which has observable of all events that are 
produced ... but I don't how to persist them :/

-- 
>>  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] Creating a reconnecting TCP client

[Adam]

Hi,

I've been looking for a way to create a client that upon disconnection will 
try to reconnect.
I've done this in the past with RxJava observables, but I'm not sure how to 
do this using Akka Streams.

I saw some code examples where PushStage is being used to implement this, 
but the code samples are old (the API has changed) and I'm not sure exactly 
how to migrate them correctly.
In the code examples, it seems like past versions of the API allowed 
outgoing TCP connections to be handled using a function (by calling 
handleWith), which means a lazy approach could be used.
I *think* this is no longer possible.

So I figured I can get the same effect with an approach similar to what 
I've used in the past with Rx observables - create a Source of TCP outgoing 
connection flows.
Essentially what I need is similar to a theoretic Source.repeat[T](gen: 
()=>T).
There's no such method on Source, so I implemented this using 
ActorPublisher.
I plan to also have some delay between re-connection attempts with an 
exponential backoff and also support multiple target hosts, but for now I 
only want to immediately reconnect to the same address.

If I didn't care about how many connections my client actually opens at the 
same time, I could say this approach works.
In actuality I do, of course, care and I only want a single connection to 
be open at any given time.
Unfortunately, the Request objects my ActorPublisher receives contain 
numbers larger than 1.

Is there a way to force the downstream flow to only ask for a single item 
at a time?
Alternatively, is there actually a better way to achieve my original goal 
(a TCP client that reconnects)?

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: system.scheduler.scheduleOnce consumes Heap over time

[Adam]

You can easily check what Roland suggested.

   1. Setup the frequency of the scheduling to be very fast so memory will 
   grow quickly.
   2. connect with visualvm\jconsole to the jvm and initiate gc manually.
   3. Compare the trend of memory of the moments right *after the GC* and 
   see if it's really going up
   4. If you do think there a leak, I'd take a heap dump of live objects 
   and use Eclipse MAT to pin point the retained set with its respective GC 
   root.
   

On Friday, September 4, 2015 at 11:02:02 PM UTC+3, Salvatore Rapisarda 
wrote:
>
> Hi Jeff,
>
> I'm having the same problem. And I did the same, I was thinking it was my 
> application but is the Akka actors that use all the memory ... What can I 
> do?
>
> Salvo
>
> On Tuesday, 12 May 2015 07:02:51 UTC+1, Jeff Steinmetz wrote:
>>
>> I thought there was something specific I was doing wrong in an 
>> application I have deployed in development, which eventually needs to be 
>> production ready.
>>
>> Over time, the Akka actor system slowly consumes all available memory.  I 
>> assumed it was a memory leak that I introduced, but as it turns out, even 
>> the sample Typesafe "hello-akka" app demonstrates the same heap consumption.
>>
>> http://www.typesafe.com/activator/template/hello-akka
>>
>>
>> If you let the sample application above run for a "very long", the heap 
>> usage slowly grows, and is never released.  Although, it is "Very Slow"
>> Since it is set to send a message to the "greeter" only every 1 second, 
>> this isn't very apparent.  
>>
>> I simplified the pattern I am using in an actual application, that 
>> demonstrates the same issue, but at an accelerated rate.
>> This is modeled after the "Scheduling Periodic Messages" pattern 
>> described here:
>>
>> http://doc.akka.io/docs/akka/snapshot/scala/howto.html
>>
>>
>> The full sample code to recreate the memory consumption, with heap usage 
>> logging is available at the gist below.  (note: if you start with the 
>> hello-akka sample application, and replace "HelloAkkaScala.scala" with this 
>> gist below, you can reproduce.  You will need to add to your build.sbt the 
>> following (as mentioned in the comments at the top of the gist)
>>
>>   "com.kenshoo" %% "metrics-play" % "2.3.0_0.1.9"  
>>
>> https://gist.github.com/jeffsteinmetz/bbccb4815858620ab5a2
>>
>> You may need to let it run for about 1 to 2 minutes before you see the 
>> "initial" bump in heap usage.  After that, you will see it slowly climb and 
>> never back down.
>> Note - the metrics calls are not required, and do not cause the memory 
>> leak - you can watch system memory without this library and see the same 
>> issue.
>>
>> I've tried a few versions of Akka, with the same results.  In production, 
>> a similar (real world) application eventually consumes all memory.
>>
>> Hoping for a little insight on the Akka internals, and potential solution.
>>
>> J
>>
>>
>>
>>
>>
>>

-- 
>>  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 Akka actors deadlock?

[Adam]

What kind of web container (if any are you using)?

I'd say using ask and blocking on it is still an improvement with pre 3.0 
servlets.

With asynchronous servlets you can push the AsyncContext down in a message or 
use as in the ask future's onComplete callback.

With other frameworks (Netty, Jetty, Akka HTTP, non blocking 3.1 servlets, 
etc.) things will be even better.

There's just no need to use ask in other places, That's all. In other words it 
makes perfect sense to use it for the integration point between your existing 
blocking code and your new Akka based code and slowly change code to or add new 
asynchronous code. 

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Setting akka log level from log4j

[Adam]

https://gist.github.com/adamhonen/8863088641df095cce96

Here, I hope that helps.

On Tuesday, August 25, 2015 at 11:52:18 AM UTC+3, Dennis Jönsson wrote:



 Den måndag 24 augusti 2015 kl. 18:58:26 UTC+2 skrev Adam:

 I've worked around this by starting an actor that polls a regular slf4j 
 logger and then changes the akka log level at run time through the event 
 bus.

 It works well enough, although it means selective log levels still incur 
 a high overhead, regardless of logging frequency and it also means that 
 enabling selective debug logs is a bit more cumbersome than what you must 
 be used to.

 I can share the code if that sounds like a reasonable solution in your 
 case.

 I think another option is using an asynchronous logger, but then if you 
 want to use the data Akka populates in the MDC for akka loggers, you'll 
 have to add it on your own.




 Thanks Adam, I would be interested in looking at the code. The only 
 solution I found sofar has been to run debug log level in AKKA at all times 
 and then filter the output through log4j. But that means Akka will have to 
 do alot of unnessecary work all the time. 


-- 
  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] Setting akka log level from log4j

[Adam]

I've worked around this by starting an actor that polls a regular slf4j logger 
and then changes the akka log level at run time through the event bus.

It works well enough, although it means selective log levels still incur a high 
overhead, regardless of logging frequency and it also means that enabling 
selective debug logs is a bit more cumbersome than what you must be used to.

I can share the code if that sounds like a reasonable solution in your case.

I think another option is using an asynchronous logger, but then if you want to 
use the data Akka populates in the MDC for akka loggers, you'll have to add it 
on your own.

-- 
  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] [Akka Streams] Designing a Full Project with Error Handling and ~100% Test Coverage

[Adam Shannon]

I thought there were plans for akka-stream to move away from actors as the
implementation detail. Is that still the case?

On Mon, Aug 24, 2015 at 1:07 PM, Gabriel Volpe volpegabr...@gmail.com
wrote:

 Hi Akkers,

 I just want to share with you my new post! In this case I'm talking about
 how to design a full project using Akka Streams dealing with error handling
 and ~100% test coverage. Also I created a demonstration project.


 https://partialflow.wordpress.com/2015/08/17/akka-streams-designing-a-full-project/

 Let me know what do you think, I'll be grateful to receive your feedback!

 Cheers,
 Gabriel.

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




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  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] [Akka Streams] Designing a Full Project with Error Handling and ~100% Test Coverage

[Adam Shannon]

If akka-actor is going to be removed from akka-stream wouldn't that impact
the ability to test the logic and functionality of your akka-stream code
with actor logic / messages?

On Mon, Aug 24, 2015 at 1:24 PM, Gabriel Volpe volpegabr...@gmail.com
wrote:

 I don't understand your question. What is the relation with the blog post?

 El lunes, 24 de agosto de 2015, 19:13:00 (UTC+1), Adam Shannon escribió:

 I thought there were plans for akka-stream to move away from actors as
 the implementation detail. Is that still the case?

 On Mon, Aug 24, 2015 at 1:07 PM, Gabriel Volpe volpeg...@gmail.com
 wrote:

 Hi Akkers,

 I just want to share with you my new post! In this case I'm talking
 about how to design a full project using Akka Streams dealing with error
 handling and ~100% test coverage. Also I created a demonstration project.


 https://partialflow.wordpress.com/2015/08/17/akka-streams-designing-a-full-project/

 Let me know what do you think, I'll be grateful to receive your feedback!

 Cheers,
 Gabriel.

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




 --
 Adam Shannon | Software Engineer | Banno | Jack Henry
 206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

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




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Specs2RouteTest equivalent for Akka HTTP

[Adam Shannon]

FYI If you want to add a class to your application here's an example:
https://gist.github.com/adamdecaf/f83c7000d1b69bc29c4d

On Tue, Aug 18, 2015 at 2:29 AM, Johannes Rudolph 
johannes.rudo...@googlemail.com wrote:

 Hi,

 specs2 testing support hasn't been ported from spray yet. The basic issue
 is that akka modules weren't allowed to depend on Scala dependencies
 because of bootstrapping issues when releasing a new Scala version that
 includes Akka. I'm not completely sure if this is still the most recent
 information on the topic so I created
 https://github.com/akka/akka/issues/18246 to clarify the issue.

 Thanks for the report,
 Johannes


 On Tuesday, August 18, 2015 at 4:38:58 AM UTC+2, Everson Alves da Silva
 wrote:

 Hi,

 We are starting a new project at work and we chose to use Akka HTTP for
 the API. So far everything is working as expected and the docs/tutorials
 for spray work without changes or with minimal changes.

 However, now that we want to add integration tests for the routes, the
 examples that fits our needs in spray are done using Specs2RouteTest or
 Scalatest. We have a somewhat large codebase that uses Specs2 and don't
 want to introduce Scalatest. Is there an equivalent for Specs2RouteTest on
 Akka HTTP?

 Regards,
 @johnny_everson https://twitter.com/johnny_everson


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




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  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] Performance question

[Adam]

The general answer similar questions usually get here is that you'll have to 
measure, but here are a few comments:

1. I'd check what's causing these spikes. The usual suspect is GC.
2. You didn't mention what handling such a request means. Optimally with 2 
cores you have 2000ms per second worth of processing (of course you will have a 
bit less left for you), so if your requests spend the entire 20ms doing actual 
processing, you can't surpass 100 reqs/sec.
If on the other hand you only spend 2ms in the JVM and an extra 18 waiting 
(where waiting means freeing the thread to handle other actors) for some non 
blocking IO operation, then your max is 1000 (and so on).
3. My experience, on my hardware, has been that routers can easily surpass 1500 
reqs/sec, but I refer you to my first sentence...

-- 
  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] Announce: akka-http dropwizard / codahale metrics integration

[Adam Shannon]

Hey all,

We've been working on integrating some codahale metrics into akka-http. 
This has been heavily by the spray PR[0], but ported over to the akka-http 
classes.  

https://github.com/Backline/akka-http-metrics

We're running this in production for a little while now and would love it 
if others would contribute their ideas and improvements!

[0]: https://github.com/spray/spray/pull/359

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

Viktor,

My main concern here has been the throwing of exceptions. It was a bit
confusing to see that (along with Internal server error, sending 500
response) when it seems akka-http is handling this fine.

It seems like when trying to re-produce this with curl akka-http responds
with a 400 as per RFC2616:
https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

So perhaps this is with an http client that is intentionally not setting
the Host header at all?

Another thing of note with this. If your akka-http instances are behind a
properly functioning proxy or load balancer I don't think you'd be impacted
by this, because nginx seems to be properly handling these requests.

On Mon, Jul 20, 2015 at 4:21 AM, Viktor Klang viktor.kl...@gmail.com
wrote:

 Hi Adam,

 What should it do instead of throwing the exception?
 (In case it is legal according to the HTTP spec please point the section
 out to me, thanks!)

 On Mon, Jul 20, 2015 at 7:08 AM, Adam Shannon adam.shan...@banno.com
 wrote:

 I wouldn't say undesired behavior so much as something that we should
 work to fix within akka-http as to not throw the exception. I'm not seeing
 app crashes as have been reported by others.

 Ernesto, do you have a stand alone case? I could probably create one if
 not.

 On Sun, Jul 19, 2015 at 5:00 PM, Viktor Klang viktor.kl...@gmail.com
 wrote:

 Adam,

 thank you. Are you observing any undesired behavior from Akka Http
 related to those requests?

 On Sun, Jul 19, 2015 at 10:43 PM, Adam Shannon adam.shan...@banno.com
 wrote:

 I have some logs of this happening to me as well. I'm running on EC2 in
 us-east-1. I've got nginx and elb in front of these akka-http instances.
 Here's a few stack traces from the instances as well as nginx access logs.

 https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

 These requests aren't killing my jvm instances fyi. I'm on akka-http-*
 1.0

 On Sun, Jul 19, 2015 at 2:33 PM, Viktor Klang viktor.kl...@gmail.com
 wrote:

 Do you have a copy of the actual HTTP request that we could use as a
 regression test?

 On Sun, Jul 19, 2015 at 8:26 PM, Ernesto Menéndez pya...@gmail.com
 wrote:

 I received the same request several times when I was hosting my
 service at DigitalOcean using akka-http RC4. I had to restart the service
 each time.

 Now that I moved my service to another provider and updated to
 akka-http 1.0, I still haven't got this kind of request or maybe I just
 haven't noticed as It has been working fine for a couple of hours.  I'll
 let you know if I see the problem again.



 On Sunday, July 19, 2015 at 9:53:47 AM UTC-6, Nicolau Werneck wrote:

 I am working on this pet project of mine, and I had an HTTP service
 built with akka-http on-line. The other day I found out it was 
 unavailable,
 and when I checked in the logs it appears I was a victim of this attack:

 http://www.skepticism.us/2015/05/13/

 I lost the error message, but it was pretty clear that the described
 request dropped my server, and the problem was the absence of the `Host`
 header.

 Now, isn't this something akka-http, or any HTTP server or
 framework, should be robust to? Is there anything I should or could have
 done as a user to prevent this problem, or should I be filing a bug 
 report?
 Also, what is a proper way to keep the service running? I was just 
 calling
 sbt from the command line, really experimental, I know there are better
 ways out there but I don't know where to start.

 Thanks,
 ++nic

  --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Adam Shannon | Software Engineer | Banno | Jack Henry
 206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

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

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

Viktor,

All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header
field.

Is from RFC 2616

I can confirm (the gist above) that akka-http is doing that with curl -H
host:  However, what I haven't confirmed yet is what akka-http is doing
with no Host header present. (I'd need to fork some well-conforming library
and break it.)

On Mon, Jul 20, 2015 at 8:15 AM, Viktor Klang viktor.kl...@gmail.com
wrote:

 Adam,

 you'd like Akka Http to respond with a 400 in case Host is omitted?
 What does the spec mandate?


 On Mon, Jul 20, 2015 at 3:09 PM, Adam Shannon adam.shan...@banno.com
 wrote:

 Viktor,

 My main concern here has been the throwing of exceptions. It was a bit
 confusing to see that (along with Internal server error, sending 500
 response) when it seems akka-http is handling this fine.

 It seems like when trying to re-produce this with curl akka-http responds
 with a 400 as per RFC2616:
 https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

 So perhaps this is with an http client that is intentionally not setting
 the Host header at all?

 Another thing of note with this. If your akka-http instances are behind a
 properly functioning proxy or load balancer I don't think you'd be impacted
 by this, because nginx seems to be properly handling these requests.

 On Mon, Jul 20, 2015 at 4:21 AM, Viktor Klang viktor.kl...@gmail.com
 wrote:

 Hi Adam,

 What should it do instead of throwing the exception?
 (In case it is legal according to the HTTP spec please point the section
 out to me, thanks!)

 On Mon, Jul 20, 2015 at 7:08 AM, Adam Shannon adam.shan...@banno.com
 wrote:

 I wouldn't say undesired behavior so much as something that we should
 work to fix within akka-http as to not throw the exception. I'm not seeing
 app crashes as have been reported by others.

 Ernesto, do you have a stand alone case? I could probably create one if
 not.

 On Sun, Jul 19, 2015 at 5:00 PM, Viktor Klang viktor.kl...@gmail.com
 wrote:

 Adam,

 thank you. Are you observing any undesired behavior from Akka Http
 related to those requests?

 On Sun, Jul 19, 2015 at 10:43 PM, Adam Shannon adam.shan...@banno.com
  wrote:

 I have some logs of this happening to me as well. I'm running on EC2
 in us-east-1. I've got nginx and elb in front of these akka-http 
 instances.
 Here's a few stack traces from the instances as well as nginx access 
 logs.

 https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

 These requests aren't killing my jvm instances fyi. I'm on
 akka-http-* 1.0

 On Sun, Jul 19, 2015 at 2:33 PM, Viktor Klang viktor.kl...@gmail.com
  wrote:

 Do you have a copy of the actual HTTP request that we could use as a
 regression test?

 On Sun, Jul 19, 2015 at 8:26 PM, Ernesto Menéndez pya...@gmail.com
 wrote:

 I received the same request several times when I was hosting my
 service at DigitalOcean using akka-http RC4. I had to restart the 
 service
 each time.

 Now that I moved my service to another provider and updated to
 akka-http 1.0, I still haven't got this kind of request or maybe I just
 haven't noticed as It has been working fine for a couple of hours.  
 I'll
 let you know if I see the problem again.



 On Sunday, July 19, 2015 at 9:53:47 AM UTC-6, Nicolau Werneck wrote:

 I am working on this pet project of mine, and I had an HTTP
 service built with akka-http on-line. The other day I found out it was
 unavailable, and when I checked in the logs it appears I was a victim 
 of
 this attack:

 http://www.skepticism.us/2015/05/13/

 I lost the error message, but it was pretty clear that the
 described request dropped my server, and the problem was the absence 
 of the
 `Host` header.

 Now, isn't this something akka-http, or any HTTP server or
 framework, should be robust to? Is there anything I should or could 
 have
 done as a user to prevent this problem, or should I be filing a bug 
 report?
 Also, what is a proper way to keep the service running? I was just 
 calling
 sbt from the command line, really experimental, I know there are 
 better
 ways out there but I don't know where to start.

 Thanks,
 ++nic

  --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

Would https://github.com/akka/akka/issues/17992 have impacted 1.0-M2 ? I
upgraded from M2 to 1.0 this weekend and I never saw the server dying from
these requests.

On Mon, Jul 20, 2015 at 9:26 AM, 'Johannes Rudolph' via Akka User List 
akka-user@googlegroups.com wrote:

 On Mon, Jul 20, 2015 at 3:59 PM, Nicolau Werneck nwern...@gmail.com
 wrote:
  It is unfortunate that I missed my error logs, but I'm glad you guys are
  taking a look at this!
 
  I confirmed that removing the Host header with curl just gives a 400, so
 it
  can't but just this. I was using 1.0-RC4, so maybe it was related to
 #17992?

 Yes, it seems both you and Adam suffered from #18044 which means that
 HTTP/1.0 requests without a Host header failed noisily. But you were
 probably additionally affected by #17992 which (dependently of #18044
 or not) unbound the server for some error conditions.


 Johannes

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




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

Johannes,

Yes, that seems to be the only issue left that I have. I'm not sure if
Nicolau is having any other issues.

On Mon, Jul 20, 2015 at 8:33 AM, 'Johannes Rudolph' via Akka User List 
akka-user@googlegroups.com wrote:

 Hi Adam,

 On Mon, Jul 20, 2015 at 3:25 PM, Adam Shannon adam.shan...@banno.com
 wrote:
  All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad
 Request)
  status code to any HTTP/1.1 request message which lacks a Host header
  field.
 
  Is from RFC 2616
 
  I can confirm (the gist above) that akka-http is doing that with curl -H
  host:  However, what I haven't confirmed yet is what akka-http is doing
  with no Host header present.

 curl isn't sending any Host-header with the snippet you posted. From
 curl's documentation:

  Remove an internal header by giving a replacement without content on the
 right side of the colon, as in: -H Host:.

 So, what is the remaining issue here?

 Is it that akka-http behaves well regarding the spec but logs some
 spurious errors and pretends to respond with 500?

 Johannes

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




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

I have some logs of this happening to me as well. I'm running on EC2 in
us-east-1. I've got nginx and elb in front of these akka-http instances.
Here's a few stack traces from the instances as well as nginx access logs.

https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

These requests aren't killing my jvm instances fyi. I'm on akka-http-* 1.0

On Sun, Jul 19, 2015 at 2:33 PM, Viktor Klang viktor.kl...@gmail.com
wrote:

 Do you have a copy of the actual HTTP request that we could use as a
 regression test?

 On Sun, Jul 19, 2015 at 8:26 PM, Ernesto Menéndez pya...@gmail.com
 wrote:

 I received the same request several times when I was hosting my service
 at DigitalOcean using akka-http RC4. I had to restart the service each time.

 Now that I moved my service to another provider and updated to akka-http
 1.0, I still haven't got this kind of request or maybe I just haven't
 noticed as It has been working fine for a couple of hours.  I'll let you
 know if I see the problem again.



 On Sunday, July 19, 2015 at 9:53:47 AM UTC-6, Nicolau Werneck wrote:

 I am working on this pet project of mine, and I had an HTTP service
 built with akka-http on-line. The other day I found out it was unavailable,
 and when I checked in the logs it appears I was a victim of this attack:

 http://www.skepticism.us/2015/05/13/

 I lost the error message, but it was pretty clear that the described
 request dropped my server, and the problem was the absence of the `Host`
 header.

 Now, isn't this something akka-http, or any HTTP server or framework,
 should be robust to? Is there anything I should or could have done as a
 user to prevent this problem, or should I be filing a bug report? Also,
 what is a proper way to keep the service running? I was just calling sbt
 from the command line, really experimental, I know there are better ways
 out there but I don't know where to start.

 Thanks,
 ++nic

  --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google Groups
 Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google Groups
 Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Server attacked. What could have been done?

[Adam Shannon]

I wouldn't say undesired behavior so much as something that we should work
to fix within akka-http as to not throw the exception. I'm not seeing app
crashes as have been reported by others.

Ernesto, do you have a stand alone case? I could probably create one if
not.

On Sun, Jul 19, 2015 at 5:00 PM, Viktor Klang viktor.kl...@gmail.com
wrote:

 Adam,

 thank you. Are you observing any undesired behavior from Akka Http related
 to those requests?

 On Sun, Jul 19, 2015 at 10:43 PM, Adam Shannon adam.shan...@banno.com
 wrote:

 I have some logs of this happening to me as well. I'm running on EC2 in
 us-east-1. I've got nginx and elb in front of these akka-http instances.
 Here's a few stack traces from the instances as well as nginx access logs.

 https://gist.github.com/SpicyMonadz/b844ce4503e145fda7ee

 These requests aren't killing my jvm instances fyi. I'm on akka-http-*
 1.0

 On Sun, Jul 19, 2015 at 2:33 PM, Viktor Klang viktor.kl...@gmail.com
 wrote:

 Do you have a copy of the actual HTTP request that we could use as a
 regression test?

 On Sun, Jul 19, 2015 at 8:26 PM, Ernesto Menéndez pya...@gmail.com
 wrote:

 I received the same request several times when I was hosting my service
 at DigitalOcean using akka-http RC4. I had to restart the service each 
 time.

 Now that I moved my service to another provider and updated to
 akka-http 1.0, I still haven't got this kind of request or maybe I just
 haven't noticed as It has been working fine for a couple of hours.  I'll
 let you know if I see the problem again.



 On Sunday, July 19, 2015 at 9:53:47 AM UTC-6, Nicolau Werneck wrote:

 I am working on this pet project of mine, and I had an HTTP service
 built with akka-http on-line. The other day I found out it was 
 unavailable,
 and when I checked in the logs it appears I was a victim of this attack:

 http://www.skepticism.us/2015/05/13/

 I lost the error message, but it was pretty clear that the described
 request dropped my server, and the problem was the absence of the `Host`
 header.

 Now, isn't this something akka-http, or any HTTP server or framework,
 should be robust to? Is there anything I should or could have done as a
 user to prevent this problem, or should I be filing a bug report? Also,
 what is a proper way to keep the service running? I was just calling sbt
 from the command line, really experimental, I know there are better ways
 out there but I don't know where to start.

 Thanks,
 ++nic

  --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives:
 https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Adam Shannon | Software Engineer | Banno | Jack Henry
 206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google Groups
 Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google Groups
 Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options

[akka-user] akka-http/spray REST API documentation?

[Adam]

Looks like there's something for spray:

http://github.com/gettyimages/spray-swagger

I imagine there's nothing for Akka HTTP, seeing as it's not even officially 
released 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.

[akka-user] Re: [akka-http] akka-http-session project: client-side sessions, remember me, csrf

[Adam Warski]

 You have something similar in concept to what Play Framework uses for 
 sessions today. Nothing wrong with that per say, but writing secure 
 protocols (session serialization and shared trust) is hard for non trivial 
 implementations. 


That's exactly my intention, that is to extract the essence of session 
management as a possibly minimal library. Where possible I tried to base 
the impl on what's in Play, as I trust them to do the right thing (the 
comments in code point to pieces which are taken from Play)
 

 *For example:* The security effect of the Hmac SHA-1 that you are using 
 is a function of the key size (5.3.4 Security Effect of the HMAC Key 
 http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf) 
 the 
 user chooses. But you do not mandate what the minimal length is in your 
 implementation. Even with a larger key, using Hmac SHA-256 instead, with 
 a minimal key size of 256 bits is a safer bet 
 http://tools.ietf.org/html/rfc7518#section-3.2.


Right, maybe it would be a good idea to mandate a minimal key, or at least 
warn. Currently I provide a method to generate a good, long server 
secret. 
 

 Your implementation, like Play Framework, limits the signature to a 
 symmetrical pre shared secret (HMAC and AES). This is effective for basic 
 scenarios but limiting if you'd wish to not trust all services that 
 consumes the session, since anyone verifying the session needs your secret 
 and is therefore able to modify the session.


Well the signature is a hash, the optional encryption of the data is 
symmetrical. You can also trivially provide your own signature/encryption 
implementation by substituting one class. The sessions are meant to be 
verified/decrypted only on the server, but if you'd like to verify them 
elsewhere, then yes, you need to share the key.
 

 Without steering you off your current path, I just wish to mention JWT 
 (Json Web Token) which is a token forma http://jwt.iot typically sent 
 as a OAuth2 Bearer Token (using the HTTP Authorization header). JWT has 
 security considerations as well as a client side singed session (claims) 
 addressed in a standardized way with support for both symmetrical and 
 asymmetrical signature and encryptions. 


I read about JWT, from what I understand it's kind of a combination of how 
header-based CSRF protection works and keeping the content of the cookie in 
memory only, (instead in the cookie).

Also, if you want to implement remember me, I suppose you need to resort 
to cookies anyway to have some kind of persistent client-side storage?
 

 I'm not suggesting that you abandon your current path but reading the 
 standards 
 around OpenID Connect http://openid.net/connect/ might be a source of 
 inspiration as they are well written and talk about many subtle security 
 considerations (scroll down and look at the underpinnings group, read about 
 JWA, JWK, JWS, JWE, JWT)

 

 If you do want to use JWT then know that implementing all of JWT (or 
 OpenID Connect for that matter) from scratch is quite a task, but there are 
 well written and easy to use libraries such as Jose4j 
 https://bitbucket.org/b_c/jose4j/wiki/Home available. One caveat is 
 that the client needs to add the JWT itself to a header, that implies a web 
 page where you call APIs via javascript.


Thanks for the links! I know the basic ideas behind the auth protocols, but 
it's always interesting to read up some details :)

I suppose adding JWT would be a good addition to the library at some point, 
as an alternative method of implementing sessions. Feel free to create a GH 
issue if you think that would be a good idea :)

Adam
 

 Good luck going forwards! Libraries like these are very useful.
 /Magnus
 Den fredag 10 juli 2015 kl. 16:41:17 UTC+2 skrev Adam Warski:

 Hello,

 I started recently working on a small side-project containing akka-http 
 directives to handle client-side sessions, csrf protection and remember-me. 
 The motivation is to fill in the missing piece necessary to use akka-http 
 as a backend for SPA webapp.

 I'd like things to be quite secure, hence:

 * the sessions are signed, optionally encrypted and with an optional 
 expiry date
 * csrf uses headers as the preferred method of submitting the token (in 
 addition to a cookie)
 * remember-me hashes tokens, uses selectors in addition to tokens

 Sessions are typed, so it's quite easy to store a simple case class 
 (client-side).

 Here's the github repo: https://github.com/softwaremill/akka-http-session
  
 which also contains a very-very simply example app:

 https://github.com/softwaremill/akka-http-session/blob/master/example/src/main/scala/com/softwaremill/example/Example.scala

 The project is just over a week old, so code reviews / comments / etc. 
 more than welcome :)

 Adam



-- 
  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] Re: [akka-http] akka-http-session project: client-side sessions, remember me, csrf

[Adam Warski]

 I recommend just keeping cookies out of the equation, that makes CSRF 
 issues go away which gives you a simpler implementation. 


I had the impression that cookies are still the way things are done, and 
to be honest didn't really consider not using them at all. But it seems I 
should revise that :)
 

 Some answers below, hope you don't mind the long answers :) 


Quite the contrary, it's great to get your opinions and review!
 

 Where possible I tried to base the impl on what's in Play, as I trust them 
 to do the right thing 

 Well, not a bad starting point, but I imagine Play has legacy and 
 backwards compatibility to consider (cookies) and does server side 
 rendering. I'm suggesting what is right for Play might just be OK for a 
 green field library.

 

 I read about JWT, from what I understand it's kind of a combination of how 
 header-based CSRF protection works and keeping the content of the cookie in 
 memory only, (instead in the cookie).


 CSRF protection is only needed because of the use of cookies or Basic Auth 
 where then the browser automatically attaches the authentication/cookie to 
 each request for a domain. If you don't have to be backwards compatible 
 with a cookie based client side sessions (as Play have to) then instead of 
 using CSRF protection you might as well do away with cookies altogether, if 
 you are already using header based CSRF then you actually gain simplicity.


So you would need to send the session token (in any data format really, I 
guess it can also be the same content as the cookie I'm constructing 
currently) in a custom header, and you would get CSRF protection for 
free, though it would only work for AJAX requests. 
 

 With JWT you do commonly send the token as a header (Authorization: Bearer 
 your jwt). But this is not in any way mandated by JWT or JOSE (Javascript 
 Object Signing and Encryption). You can send a JWT as a POST body or as a 
 Cookie if you wish, sorry if I was misleading on that. JOSE-JWT is a data 
 format.


Well the signature is a hash, the optional encryption of the data is 
 symmetrical.

 HMAC uses symmetrical keys. You do have a point in that a MAC is not a 
 digital signature 
 http://crypto.stackexchange.com/questions/5646/what-are-the-differences-between-a-digital-signature-a-mac-and-a-hash.
  
 To verify the HMAC you need the same secret key that was used to create it. 
 That means you can create a new signature for a different message. If you 
 have a monolithic application that is fine (like Play apps) if you have 
 multiple applications or multiple small services you may not wish to 
 distribute that key to all clients that need to verify the session.


Ah, microservices, right ;) Although I suppose it's quite common to have a 
single orchestrator service which does the whole frontend job. But of 
course it doesn't have to be that way.
 

 Also, if you want to implement remember me, I suppose you need to resort 
 to cookies anyway to have some kind of persistent client-side storage?


 Yes browser Local Storage should fit well. The advantage of Local Storage 
 over cookies is again no CSRF issues. In the case of JWT a remember me 
 could just be a JWT with a long expiration.


When using Local Storage, would you still separate the current session 
data - containing the signed/encrypted user id or username (that would go 
to sessionStorage) and a remember me token (stored in localStorage) like 
you do with cookies? It has some nice properties, like varying access 
levels based on automatic/manual logins or knowing when users log in 
(automatically or manually).

Thanks,
Adam

-- 
  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] [akka-http] akka-http-session project: client-side sessions, remember me, csrf

[Adam Warski]

Hello,

I started recently working on a small side-project containing akka-http 
directives to handle client-side sessions, csrf protection and remember-me. 
The motivation is to fill in the missing piece necessary to use akka-http 
as a backend for SPA webapp.

I'd like things to be quite secure, hence:

* the sessions are signed, optionally encrypted and with an optional expiry 
date
* csrf uses headers as the preferred method of submitting the token (in 
addition to a cookie)
* remember-me hashes tokens, uses selectors in addition to tokens

Sessions are typed, so it's quite easy to store a simple case class 
(client-side).

Here's the github repo: https://github.com/softwaremill/akka-http-session 
which also contains a very-very simply example app:
https://github.com/softwaremill/akka-http-session/blob/master/example/src/main/scala/com/softwaremill/example/Example.scala

The project is just over a week old, so code reviews / comments / etc. more 
than welcome :)

Adam

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: how do I use the scala repl to inspect a in java written actor system.

[Adam]

scala -cp your jar

On Monday, June 29, 2015 at 11:58:14 AM UTC+3, john@gmail.com wrote:

 Sorry that  I know so little about scala. 
 I have written a java akka system which uses maven for dependeny 
 management.

 I would now like to inspect my configuration (Typesafe Config Library 
 https://github.com/typesafehub/config) with a scala repl. 
 This is described in 
 http://doc.akka.io/docs/akka/2.3.11/general/configuration.html 
 Logging of Configuration


 How do I import my jar into the scala repl so that I can inspect with the 
 repl my cofig?





-- 
  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] DynamoDB snapshot plugin?

[Adam]

 

There’s actually one thing you need to take into account when using 
DynamoDB for persistence.

I've been bitten by this a few times when using other Amazon services.


The Java SDK provided by Amazon includes two interfaces: synchronous and 
asynchronous.

I imagine you’d prefer to use the asynchronous API as part of an Akka 
application, but unlike what you often encounter with other such dual APIs, 
the asynchronous API in this case is implemented as a wrapper around the 
synchronous API (using a thread pool) which uses blocking IO. What I’m at 
least used to with other NoSQL clients is having things the other way 
around – an asynchronous client that uses non-blocking IO and a synchronous 
wrapper around it, but that’s not currently the case with the Amazon Java 
SDK. 

 

Given that each operation is actually an HTTP call to the amazon service 
(not sure if there's any batching going on internally, but probably not), 
they can get pretty pricy.

You will need to make sure that you don’t send requests to Amazon faster 
than the client can handle it.

It’s not just a question of overflowing the thread pool, you can also get 
terrible latency for some of the requests this way as they get queued in 
your JVM, which depending on your system, might not be acceptable.

Another option is to make the HTTP calls using your own non-blocking 
client, but that comes with a larger price tag for development time.


And then again, perhaps it's not really an issue in your case and you won't 
even come close to suffering from this.


On Saturday, June 20, 2015 at 8:36:09 PM UTC+3, Bill Goldsworthy wrote:

 OK, good to know, thanks!

 On Friday, June 19, 2015 at 11:24:50 AM UTC-5, Konrad Malawski wrote:

 Hi Bill,
 I don't see a reason why such implementation wouldn't make sense - in 
 fact many of the other NoSQL stores nowadays are very dynamo inspired :-)
 So I'd say it's just a matter of actually sitting down and implementing 
 it.

 PS: We're in the middle of the final adjustment phase in Akka Persistence 
 (plugin APIs *slightly* affected), after which Persistence will soon become 
 a stable module (yay!).

 -- Konrad

 On Fri, Jun 19, 2015 at 4:20 PM, Bill Goldsworthy bgol...@gmail.com 
 wrote:

 Greetings,

 Is there a DynamoDB snapshot plugin for akka-persistence available 
 anywhere? There is not one listed on the community page and my searches 
 have been fruitless. If not, is this because of technical limitations with 
 DynamoDB or simply because one hasn't been created yet?

 Thank you,
 Bill Goldsworthy

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




 -- 
 Cheers,
 Konrad 'ktoso' Malawski
 Akka http://akka.io/ @ Typesafe http://typesafe.com/
  


-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: New Android app that uses Akka

[Adam Mackler]

On Sat, Jun 13, 2015 at 8:11 PM, Sebastian M Cheung 
minsche...@googlemail.com wrote:

 Hi Adam,

 I just saw your post, and I am also keen on building more Scala based
 Android apps but I couldn't find any good tutorials.

 So from your experience it was worth the effort that you managed to use
 Scala in Android?


Hi  Sebastian:

Was it worth the effort?  Is that a trick question?  Writing an Android app
in Scala must be *less* effort than using Java.  Actually I am unsure,
because I've never written an Android app in Java.  Android apps require
competent handling of concurrency, and trying to do that without Akka must
be more difficult, no?

The main thing is that native Android provides its own mechanism to
accomplish the equivalent of telling an Akka message,   See here
https://developer.android.com/training/multiple-threads/communicate-ui.html.
You need to understand and integrate that with Akka's message passing when
updating the UI.  Other than that, why hurt yourself on Java's concurrency?

It has been a while since I've done any Android programming, but I did
release one app you might look at.  It's a simple metronome for musicians.
The app is on Play
https://play.google.com/store/apps/details?id=org.mackler.metronome, and
the source code is on bitbucket
https://bitbucket.org/mackler/safe-metronome.  Note also that there are
Scala+Android facilities I've never used and I'm sure there is much that's
possible beyond what I have tasted.  Here are some promising links you
might already know about:

   - Scaloid https://github.com/pocorall/scaloid/blob/master/README.md
   - An article about using Scaloid
   
http://www.drdobbs.com/mobile/developing-android-apps-with-scala-and-s/240161584
   - You probably already know about SBT-Android
   http://fxthomas.github.io/android-plugin/, which I believe is
   superseded by
   - The Android SDK Plugin for SBT
   https://github.com/pfn/android-sdk-plugin/blob/master/README.md, which
   is currently maintained
   - The scala-on-android Google Group
   https://groups.google.com/forum/#!forum/scala-on-android

Those are just from my notes of a few years ago.  I'm sure the
state-of-the-art has progressed since then.

Happy coding,
--
Adam Mackler

-- 
  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] [akka-streams] FlexiMerge/FlexiRoute parameters

[Adam Warski]

 I've been writing some simple code using FlexiMerge/FlexiRoute, and I'm 
 wondering why both have a single required OperationAttributes parameter? 
 Maybe there should be a * at the end to allow 0-* such parameters?


 You can combine attributes with the and combinator if you want to attach 
 more than one.


Can I attach 0? :)
 

 A side-question, I'm not really sure why this is so, but when I have a 
 Merge, I can just do:

 in ~ merge ~ out

 But when I have a FlexiMerge, I need to do:

 in ~ flexiMerge.in0
  flexiMerge.out ~ out

 it seems Merge's shape is also an Inlet, but I can't find that in the 
 code :)


 No, Merge has a shape of UniformFanIn. The sugared version of connecting 
 merge/broadcast only works because the DSL understands UniformFanin/Fanout 
 shapes, but it does not know about other shapes, since they can have 
 different types for each port (inlet/outlet). 


Ah! Now I have:

class SplitRoute[T](splitFn: T = Either[T, T]) extends FlexiRoute[T, 
UniformFanOutShape[T, T]](
  new UniformFanOutShape(2), OperationAttributes.name(SplitRoute)) { ... }

and I can use the nicer DSL.

Thanks,
Adam 

-- 
  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] Instrumenting Akka

[Adam]

You can take 2 heap dumps a day or more apart and then use Eclipse MAT to 
compare them (there's a compare basket feature that is very useful in such 
cases).

Actually there's a good chance that even a single heap dump will suffice if the 
JVM has been running for long enough. Try to use the leak suspects report. It 
usually points to the right place.

-- 
  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] Akka http load balancer

[Adam Shannon]

Is there a specific reason to not use another piece of software for this?
I'm thinking of something like nginx or haproxy. Both of which are much
more hardened and performant in regards to serving as proxies for HTTP
traffic.

On Wed, May 27, 2015 at 7:34 AM, Viktor Klang viktor.kl...@gmail.com
wrote:



 On Wed, May 27, 2015 at 2:33 PM, Viktor Klang viktor.kl...@gmail.com
 wrote:



 On Wed, May 27, 2015 at 2:01 PM, Endre Varga endre.va...@typesafe.com
 wrote:

 Hi,

 Instead of Http.request, you should use the Flow returned by
 Http.superPool() (see
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
 That flattens out the Futures and you get responses instead. That also
 makes Balance actually aware of response times.

 OTOH I don't think performance wise akka-http is currently up to the
 task of being a balancer.


 …at the moment.


 Doh, that currently eluded me, see my response as emphasis :)





 -Endre

 On Wed, May 27, 2015 at 1:21 PM, zergood zergoodso...@gmail.com wrote:

 Hello!

 I have a task to develop a http balance loader for my 2 servers. Here
 is my qucik and very dirty implementation
 https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main problem
 with it is performance, this solution is slower than my single server.
 What is the reason of performance degradation? Could you give me any
 advices how to make http load balancer with akka-http? I am using
 scala-2.11 and akka-http 1.0-RC3.

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




 --
 Cheers,
 √




 --
 Cheers,
 √

 --
  Read the docs: http://akka.io/docs/
  Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
 ---
 You received this message because you are subscribed to the Google Groups
 Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  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] [akka-streams] FlexiMerge/FlexiRoute parameters

[Adam Warski]

Hello,

I've been writing some simple code using FlexiMerge/FlexiRoute, and I'm 
wondering why both have a single required OperationAttributes parameter? 
Maybe there should be a * at the end to allow 0-* such parameters?
For lack of a better value, I'm currently using OperationAttributes.name, 
but that makes the code a bit noisy, as I already have to name the shape, 
e.g.:

class SplitRoute[T](splitFn: T = Either[T, T]) extends FlexiRoute[T, 
FanOutShape2[T, T, T]](
  new FanOutShape2(SplitRoute), OperationAttributes.name(SplitRoute)) { 
... }

A side-question, I'm not really sure why this is so, but when I have a 
Merge, I can just do:

in ~ merge ~ out

But when I have a FlexiMerge, I need to do:

in ~ flexiMerge.in0
 flexiMerge.out ~ out

it seems Merge's shape is also an Inlet, but I can't find that in the code 
:)

-- 
Thanks,
Adam

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Reasons why Logback is recommended for Akka logging

[Adam]

Hi,

Where I work, we're using Akka with log4j2 (through slf4j binding) in 
production.
We're handling billions of daily requests and so far it works flawlessly :-)

On Thursday, May 21, 2015 at 10:55:22 AM UTC+3, monika singhal wrote:

 Anyone tried log4j2 with Akka ? 

 Thanks,
 Monika




-- 
  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] What happens to unhandled(message)?

[Adam]

Unhandled is mainly useful for troubleshooting. Akka won't check if you 
actually did something with the message or not. It also doesn't force you to 
call unhandled and probably (never tried this) does't prevent you from calling 
unhandled multiple times. The documentation goes into detail regarding what 
exactly happens when you call unhandled.

Akka likewise has no black magic that checks your logic (e.g. through byte 
code injection). If you've failed to call become or do anything else you should 
have done, the you have a bug and Akka provides the tools to help you track it 
down. For example, calls to unhandled can be translated to debug messages via 
configuration.

-- 
  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] Overriding default configuration

[Adam]

First of all, regardless of inclusion, you need your build to exclude this 
application.conf file from jars. There's not much point for a configuration 
file that can't be easily modified. It should instead be in a folder (e.g. 
./conf) that is added to your classpath.

Then, you can either add your own file with an include directive for 
application.conf and load your file as the main one via the system property, or 
you can have your build rename the original application.conf (e.g. to 
some-lib.conf) and name your file application.conf and again use the include 
directive with the name you picked.

-- 
  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] Number of actors

[Adam]

Hi,

First of all, actors are very lightweight and you can have many of them, while 
an ActorSystem is heavyweight and you should not have many of that (typically 
you'd have one).

As for the pattern you describe - it all depends on the fine details, but if I 
had to implement a service that needs to get a set of details and was permitted 
(and required) to return partial results depending on some timeout, I'd have 
one actor to manage the request, sending the smaller sub requests and I'd 
indeed use the scheduler to cut this off if tge timeout expires.

It might be useful for you to take a look at the aggregator pattern referenced 
from the docs. It has a lot in common with this.

-- 
  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] Java : How should Futures be handled when Unit testing?

[Adam Daines]

Thank you both for the quick and helpful responses! 
Our issue is now resolved :)

Thanks.

On Thursday, April 9, 2015 at 1:01:24 PM UTC+1, √ wrote:

 Ouch, nice catch, now we've covered both the question and the alternative 
 (Scala) :)

 On Thu, Apr 9, 2015 at 1:59 PM, Akka Team akka.o...@gmail.com 
 javascript: wrote:



 On Thu, Apr 9, 2015 at 1:33 PM, Viktor Klang viktor...@gmail.com 
 javascript: wrote:

 Does this help?


 http://christopher-batey.blogspot.se/2014/02/testing-scala-futures-with-scalatest-20.html


 That is for scala though. We usually use scala.concurrent.Await which can 
 be used like this

   assert(Await.result(myFuture, timeoutDuration) == xyz)

 This will block the test and wait until the future becomes ready. If the 
 future completes then the assertion will run. If the future fails, then 
 Await.result() will throw the exception. If the future does not complete 
 during the time defined in timeoutDuration, then it will throw A 
 TimeoutException.

 -Endre
  


 On Thu, Apr 9, 2015 at 1:27 PM, Adam Daines daine...@gmail.com 
 javascript: wrote:

 Hi all,

 I've got a question in relation to the unit testing of a piece of non 
 actor code that produces a FutureActorRef via performing an 
 actorSelection().resolveOne on the ActorSystem.

 Within the Future.onFailure() a value is being set that I would like to 
 test but the Future is making use of the ActorSystem.dispatcher() which is 
 therefore causing asynchronicity issues when attempting to Assert that the 
 value has been set as expected.

 I am currently performing a Thread.sleep() within the Unit test to 
 provide enough time for the value to have been set but this is far from 
 ideal! 

 What is the best way to go about testing this type of code without 
 having to sleep and wait? Is it possible to override the dispatcher that 
 the ActorSystem returns with the CallingThreadDispatcher?

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




 -- 
 Cheers,
 √
  
 -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: 
 https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to the Google 
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to akka-user+...@googlegroups.com javascript:.
 To post to this group, send email to akka...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Akka Team
 Typesafe - Reactive apps on the JVM
 Blog: letitcrash.com
 Twitter: @akkateam
  
 -- 
  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 javascript:.
 To post to this group, send email to akka...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Cheers,
 √
  

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Java : How should Futures be handled when Unit testing?

[Adam Daines]

Hi all,

I've got a question in relation to the unit testing of a piece of non actor 
code that produces a FutureActorRef via performing an 
actorSelection().resolveOne on the ActorSystem.

Within the Future.onFailure() a value is being set that I would like to 
test but the Future is making use of the ActorSystem.dispatcher() which is 
therefore causing asynchronicity issues when attempting to Assert that the 
value has been set as expected.

I am currently performing a Thread.sleep() within the Unit test to provide 
enough time for the value to have been set but this is far from ideal! 

What is the best way to go about testing this type of code without having 
to sleep and wait? Is it possible to override the dispatcher that the 
ActorSystem returns with the CallingThreadDispatcher?

Thanks.

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Java : How should Futures be handled when Unit testing?

[Adam Daines]

Hi again, 

At first it had appeared that the issue was fully resolved but the test I 
had written began to fail again intermittently.  
It appears that taking the approach Endre suggested does not quite work as 
I had expected. It appears that the Await triggers and unblocks at the 
moment that the Future gets completed which is before the .onSuccess  
.onFailure have actually run. 

In my use case the variable (which is a deferredResult) is actually set 
inside the .onFailure, therefore I cannot do an assertion on it until after 
the .onFailure has finished running.

Any further assistance would be much appreciated.

Thanks.

On Thursday, April 9, 2015 at 1:46:22 PM UTC+1, Adam Daines wrote:

 Thank you both for the quick and helpful responses! 
 Our issue is now resolved :)

 Thanks.

 On Thursday, April 9, 2015 at 1:01:24 PM UTC+1, √ wrote:

 Ouch, nice catch, now we've covered both the question and the alternative 
 (Scala) :)

 On Thu, Apr 9, 2015 at 1:59 PM, Akka Team akka.o...@gmail.com wrote:



 On Thu, Apr 9, 2015 at 1:33 PM, Viktor Klang viktor...@gmail.com 
 wrote:

 Does this help?


 http://christopher-batey.blogspot.se/2014/02/testing-scala-futures-with-scalatest-20.html


 That is for scala though. We usually use scala.concurrent.Await which 
 can be used like this

   assert(Await.result(myFuture, timeoutDuration) == xyz)

 This will block the test and wait until the future becomes ready. If the 
 future completes then the assertion will run. If the future fails, then 
 Await.result() will throw the exception. If the future does not complete 
 during the time defined in timeoutDuration, then it will throw A 
 TimeoutException.

 -Endre
  


 On Thu, Apr 9, 2015 at 1:27 PM, Adam Daines daine...@gmail.com wrote:

 Hi all,

 I've got a question in relation to the unit testing of a piece of non 
 actor code that produces a FutureActorRef via performing an 
 actorSelection().resolveOne on the ActorSystem.

 Within the Future.onFailure() a value is being set that I would like 
 to test but the Future is making use of the ActorSystem.dispatcher() 
 which 
 is therefore causing asynchronicity issues when attempting to Assert that 
 the value has been set as expected.

 I am currently performing a Thread.sleep() within the Unit test to 
 provide enough time for the value to have been set but this is far from 
 ideal! 

 What is the best way to go about testing this type of code without 
 having to sleep and wait? Is it possible to override the dispatcher that 
 the ActorSystem returns with the CallingThreadDispatcher?

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




 -- 
 Cheers,
 √
  
 -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: 
 https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to the Google 
 Groups Akka User List group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to akka-user+...@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.




 -- 
 Akka Team
 Typesafe - Reactive apps on the JVM
 Blog: letitcrash.com
 Twitter: @akkateam
  
 -- 
  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.




 -- 
 Cheers,
 √
  


-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user

[akka-user] Re: Best practices for selecting or creating actor

[Adam]

First of all, you shouldn't ever block like this, as you do with Await.

As for your question - this sounds like something the parent actor should 
be responsible for.
I'm not even sure the code above works (it at least never occurred to me to 
try to create an actor using a full path as I always understood the docs as 
if it shouldn't be possible).
I think allowing the parent actor to determine if one of his children 
exists or not is cleaner.
It also has direct access to this through the actor context, so the answer 
is immediate.



On Sunday, April 5, 2015 at 10:50:28 PM UTC+3, Fatih Dönmez wrote:

 Hi,

 I want to create an actor if it didn't created already. To check its 
 existence I use actorSelection. If there is no actor defined by the path, I 
 create a new one with actorOf.
 Is this approach correct? How can I improve the design? Here is the code I 
 come up with currently;

 val fullPath: String = path.format(appId)
 var starter: ActorRef = null
 implicit val timeout = Timeout(5 seconds)

 try {
   starter = 
 Await.result(context.actorSelection(fullPath).resolveOne,FiniteDuration(5,TimeUnit.SECONDS))
 } catch {
   case e: ActorNotFound = {
 starter = context.actorOf(Props(new StarterNode(customer, appId)), 
 name = fullPath)
 logger.info(Actor [ + fullPath + ] creating for first time)
   }
   case e: Exception = logger.error(Actor [ + fullPath + ] 
 selection failed,e)
 }

 //TODO
 if(starter != null) {
   starter ! event
 } else {
   logger.warn(Starter node failed with timeout)
 }

  


-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: ANNOUNCE: Akka Streams HTTP 1.0 MILESTONE 4

[Quentin Adam]

Thx a lot for the amazing work

Already used by beta feature at Clever Cloud ;-)

Best Regards,

Le vendredi 27 février 2015 17:08:24 UTC+1, rkuhn a écrit :

 Dear hakkers,

 we are pleased to announce the availability of the fourth milestone of 
 Akka Streams  HTTP. The biggest directly visible feature of this release 
 is a completely new and fluent Java DSL for writing FlowGraphs:


1. final RunnableFlowFutureListString result = FlowGraph.factory
()
2. .closed(
3. Sink.ListString head(),
4. (builder, out) - {
5. final UniformFanOutShapeInteger, Integer bcast = builder.graph(
Broadcast.create(2));
6. final UniformFanInShapeInteger, Integer merge = builder.graph(
Merge.create(2));
7.  
8. builder.from(in).via(f1).via(bcast).via(f2).via(merge).via(f3.
grouped(1000)).to(out);
9. builder.from(bcast).via(f4).to(merge);
10. });


 The biggest internal change shines through this sample as well: the type 
 returned from the FlowGraph factory describes the result of its 
 materialization. In this example we import Sink.head() into the graph as 
 an argument to the factory method, which will propagate the materialized 
 value to the overall graph—materializing and thereby running this graph 
 will return the Future that the head-Sink materializes to. In order to wire 
 this sink up to the rest of the graph, its so-called “shape” (called “out” 
 above) is passed into the block that constructs the graph.

 Another thing to notice is that we explicitly import the Merge and 
 Broadcast junctions into the graph, yielding UniformFanInShape and 
 UniformFanOutShape, respectively. This demonstrates that our Graph type is 
 no longer “untyped”, every graph now has a Shape. A Source[T, M] is just a 
 Graph[SourceShape[T], M], which means that it has a shape that has a single 
 output and materializes to a value of type M. Please take a look at the 
 freshly rewritten documentation 
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4 to see 
 this all in action.

 You might be wondering why we did such a big change to the already quite 
 good DSL, in particular one which will break a lot of source code (sorry 
 guys and gals, but you knew what you signed up for when using pre-alpha 
 software in your projects, right? ;-) ). The reason is a deep and 
 foundational one. The central promise and design goal of Akka Streams is 
 “supreme compositionality”, we have been calling stream elements 
 “blueprints that can be freely reused”. When trying to implement these 
 semantics, we discovered that the approach of using the MaterializedMap 
 structure was fundamentally flawed: importing for example a Sink twice 
 would lead to incorrect results when trying to obtain both materialization 
 results, because the user code has only one Key in its hands. The only 
 principled solution to this problem is that materialization results must be 
 combined explicitly when multiple are generated from the same graph, and 
 this principle applies in a hierarchical fashion. For an example see the 
 docs for Java 
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/java/stream-flows-and-basics.html#Stream_Materialization
  and Scala 
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-flows-and-basics.html#Stream_Materialization,
  
 here’s an excerpt:


1. import FlowGraph.Implicits._
2. val r: RunnableFlow[(Promise[Unit], Cancellable, Future[Int])] =
3. FlowGraph.closed(source, flow, sink)((_, _, _)) { implicit builder 
=
4. (src, f, dst) = src ~ f ~ dst
5. }


 The second argument list combines the three values generated by the 
 source, flow and sink into a Tuple3 (using Scala’s lambda short-hand 
 notation, the Java example would use «(src, f, dst) - new Triplet(src, 
 f, dst)» for a suitably defined Triplet class).

 In addition to these fundamental things we have also worked on new 
 features:

- configurable supervision strategy for stream processing stages (PR 
https://github.com/akka/akka/pull/16772)
- add ContentEncoding negotiation 
https://github.com/akka/akka/issues/16593 (thanks André / @2beaucoup 
!)
- add Referer https://github.com/akka/akka/issues/16822 header to 
HTTP model
- make ShortNumber https://github.com/akka/akka/issues/16814 path 
matcher work and add minimum number to repeat 
https://github.com/akka/akka/issues/16833 modifier
- refactor HTTP RejectionHandler 
https://github.com/akka/akka/issues/16835 to make it more predictable

 For a list of all closed issues, see the milestone on github 
 https://github.com/akka/akka/issues?q=is:issue+milestone:streams-1.0-M4+is:closed
 .

 Happy hakking!


 *Dr. Roland Kuhn*
 *Akka Tech Lead*
 Typesafe http://typesafe.com/ – Reactive apps on the JVM.
 twitter: @rolandkuhn
 http://twitter.com/#!/rolandkuhn
  


-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 

[akka-user] GSOC(2015)

[adam kozuch]

Hello,
I would like to ask if anyone from Akka Team would like to be Google Summer 
of Code mentor this year?

Cheers, 
Adam Kozuch

-- 
  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] Many concurrent network connections

[Adam]

I'll refer you to here: http://doc.akka.io/docs/akka/2.3.9/dev/io-layer.html

It says Akka IO is designed with the requirement of scalability to millions of 
concurrent connections.

Of course, this typically requires tuning (including at the OS level), but 
sounds like 50k should be supported. I don't know if there was an actual test 
(millions sounds very challenging to me) to prove this to be working, but maybe 
someone of the Akka team can add that bit.

-- 
  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] Performance Of Akka IO

[Adam]

I believe 50M messages per second on a single machine was mainly an example 
for scaling up. See the kind of machine that was used for it 
http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single
.

Anyway, have you tried doing the same analysis on the legacy driver?
It would be interesting to compare the parts related to actual IO.

There's one thing (which may not be helpful to your current questions about 
Akka performance) that bothers me, but I may just be missing out on 
something obvious here, so I'll just ask: if Mongo doesn't allow a 
connection to handle more than one simultaneous request, how can any NBIO 
implementation do much better than a BIO implementation? I mean the test 
pretty much only does IO. It's not like we're using the extra free thread 
to do any other CPU intensive work while waiting on Mongo, right?
Doesn't it mean you have to hold some sort of connection pool so you can 
have more concurrent requests to Mongo in order to see any sort of benefit 
from using NBIO (Akka or not)?
When I use Akka IO in my application I often have lots of concurrent 
requests using the same socket.
They are of course kept serialized by Akka, but I can still have many 
requests on the same connection.



On Monday, February 23, 2015 at 10:57:41 PM UTC+2, Reid Spencer wrote:

 So, here's some more information from my testing which just further 
 confuses me because I’m left without a course of action to solve the 
 performance issue. I instrumented the TcpConnection actor via 
 DiagnosticActorLogging to record System.nanoTime on each log message using 
 MDC and then added some logging statements into the TcpConnection, mostly 
 to record doRead and doWrite entry and exit. I wanted to see if the problem 
 was in the actual I/O or the TcpConnection. The results are a little odd.

  
  appWait
  doRequest
  writeWait
  doWrite
  writeAck
  mongoWait
  doRead
  readWait
  doReply
   *count*
  10,000
  10,000
  10,000
  10,000
  10,000
  10,000
  10,000
  10,000
  10,000
   *sum*
  2,641,699.00
  0.00
  362,172.00
  0.00
  764,298.00
  2,836,716.00
  0.00
  413,031.00
  0.00
   *mean*
  264.17
  0.00
  36.22
  0.00
  76.43
  283.67
  0.00
  41.30
  0.00
   *median*
  217.00
  0.00
  29.00
  0.00
  55.00
  167.00
  0.00
  33.00
  0.00
   *std.dev*
  323.37
  0.00
  27.95
  0.00
  172.19
  1,162.76
  0.00
  25.92
  0.00
   *min*
  139
  0
  3
  0
  2
  125
  0
  15
  0
   *max*
  17,719
  0
  892
  0
  14,616
  22,565
  0
  1,389
  0
   
 The above data was computed by processing the log file that has repeating 
 entries like this:

 18:25:17.364UTC 917364997 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
  
 - doRequest
 18:25:17.365UTC 917364997 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
  
 - doRequest
 18:25:17.365UTC 917365026 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-10:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
  
 Entering doWrite
 18:25:17.365UTC 917365026 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-10:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
  
 Leaving doWrite
 18:25:17.365UTC 917365077 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
  
 Ack with queuelen=0
 18:25:17.365UTC 917365173 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-3:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
  
 Entering doRead
 18:25:17.365UTC 917365173 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-3:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
  
 Leaving doRead
 18:25:17.365UTC 917365202 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-3:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
  
 - doReply
 18:25:17.365UTC 917365202 DEBUG 
 [RxMongo-akka.actor.default-dispatcher-3:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
  
 - doReply
 ...

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Performance Of Akka IO

[Adam]

I think the OS you're using matters a lot for this sort of test. Hopefully 
it's not windows...

What was the maximum concurrency level that you've tested?
Did you make sure (in the performance test code) that this concurrency 
level is actually met in all cases?
Did you try tweaking with the socket options (e.g. increase the read/write 
buffers)?

It would be interesting indeed to know about ACK/NACK.
I'm using the approach of using NACK until I get failure = buffer until 
getting the resumed message = recover using ACKs.= go back to NACK once 
the buffer is cleared.
I guess it means less total messages traveling back and forth.



On Sunday, February 22, 2015 at 5:47:24 PM UTC+2, Reid Spencer wrote:

 Jim,

 I think you’re referring to this reference.conf 
 https://github.com/akka/akka/blob/master/akka-actor/src/main/resources/reference.conf
  which 
 has this section of the scheduler settings:

   # Used to set the behavior of the scheduler.
   # Changing the default values may change the system behavior drastically 
 so make
   # sure you know what you're doing! See the Scheduler section of the Akka
   # Documentation for more details.
   scheduler {
 # The LightArrayRevolverScheduler is used as the default scheduler in 
 the
 # system. It does not execute the scheduled tasks on exact time, but 
 on every
 # tick, it will run everything that is (over)due. You can increase or 
 decrease
 # the accuracy of the execution timing by specifying smaller or larger 
 tick
 # duration. If you are scheduling a lot of tasks you should consider 
 increasing
 # the ticks per wheel.
 # Note that it might take up to 1 tick to stop the Timer, so setting 
 the
 # tick-duration to a high value will make shutting down the actor 
 system
 # take longer.
 tick-duration = 10ms

 # The timer uses a circular wheel of buckets to store the timer tasks.
 # This should be set such that the majority of scheduled timeouts (for 
 high
 # scheduling frequency) will be shorter than one rotation of the wheel
 # (ticks-per-wheel * ticks-duration)
 # THIS MUST BE A POWER OF TWO!
 ticks-per-wheel = 512

 I tried various combinations for these two parameters and none of it made 
 more than a 5% difference in the numbers which is probably in the noise 
 range for my test set up. While these settings may have consequences on a 
 large actor system with lots of things going on, that’s not my situation 
 currently. I have one supervisor actor talking to one channel actor talking 
 to one TCP OutgoingConnection actor. It is pretty much linear flow of 
 messages into and out of the Akka IO code, repeated in a loop.  I’ve 
 measured the overheads of the actor system infrastructure (mailbox, message 
 send, etc.) and it is negligible (less than a microsecond). 

 Do you have any suggestions on how to look at the performance of Akka IO 
 code? Short of any suggestions from the list, I”m about to start hand 
 instrumenting the Akka IO code to find out where it spends its time. 

 Reid. 



 On Feb 21, 2015, at 6:30 PM, jimhaz...@gmail.com javascript: wrote:

 Hmm. Then I must have been playing with the setting around the same time. 
 It's definitely related to overall thread scheduling. Poke around the 
 reference.conf files in the core akka jars. There should be a description 
 of the overall methodology in there as well. Timer granularity and number 
 of buckets are the big factors. 

 -Jim

 -- Sent from my mobile device

 On Feb 21, 2015, at 2:47 PM, Reid Spencer re...@reactific.com 
 javascript: wrote:

 Jim,

 The spray-can example benchmark 
 https://github.com/spray/spray/tree/master/examples/spray-can/server-benchmark/src/main
  
 program has an application.conf 
 https://github.com/spray/spray/blob/master/examples/spray-can/server-benchmark/src/main/resources/application.conf
  
 like this:

 akka { loglevel = INFO event-handlers = [
 akka.event.slf4j.Slf4jEventHandler] actor.default-dispatcher { 
 fork-join-executor { parallelism-min = 1 parallelism-factor = 1 
 #parallelism-max 
 = 1 } }}(non-akka parts elided)

 The only interesting thing there is parallelism-factor which is 1 here 
 while I use 2. I'll try it with the lower value.

 Thanks,

 Reid.


 On Saturday, February 21, 2015 at 5:24:40 PM UTC-5, Jim Hazen wrote:

 Hi Reid,

 Sorry I don't have my IDE in front of me.  You might take a look at some 
 of Akka's scheduling configuration options.  You mentioned Spray, and 
 there's a benchmark example Spray app that ships with a pretty good 
 application.conf that exposes and tweaks some of these config values, the 
 scheduler being one of them.  AFAIK the scheduler fires completed tasks on 
 a clock/tick based timer.  You may be bumping up against the scheduler's 
 default clock timing threshold, which can be reduced.

 Hope that helps.

 -Jim


 -- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  

[akka-user] akka-http underlying threading

[Adam Shannon]

This thread in spray-user [0] got me curious about akka-http's current and
future usage of the low level mechanisms. I'm not very familiar with
akka-io underpinnings, but does it use a similar single thread for even
notifications off of the socket? If so I assume that akka-http eventually
gets down to that same point. Is this the plan going forward, or perhaps is
there some other strategy that will be used?

[0]: https://groups.google.com/forum/#!topic/spray-user/avYhEFYsvcg

-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: One-Actor-Per-Request pattern with Akka-Http

[Adam]

So why not always return OK in such cases?

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Sharing behavior among Actors in Java

[Adam]

 

Hi,
I guess the correct answer is it depends J, but I can describe what we 
use right now, as we're also using Akka (and seeing as it's been very 
rewarding to do so we do it more and more), but are confined to Java.So 
first of all, I would recommend against inheritance.
That route quickly becomes very tangled and results in a huge hierarchy of 
classes with way too many methods.

We typically use composition.
I assume the real issue is cases where you want to reuse code that relies 
on running inside an Actor.
Unfortunately UntypedActor is not an interface, so it's indeed difficult to 
mix in behavior.However, since a class method is really not much more than 
a static method that implicitly accepts the this pointer (some languages 
like python and Ada even work that way and specify all arguments 
explicitly), your actors can contain other classes that either have methods 
which accept an UntypedActor as a parameter, or accept it in their 
constructor.

We use that often for synchronous paths.

An example:

public class DbAccess {
private final UntypedActor owner;
public DbAccess(UntypedActor owner) {
this.owner = owner;
}

//methods for DB access
}

public class Auth {
private final UntypedActor owner;
public Auth(UntypedActor owner) {
this.owner = owner;
}

//methods for Authentication
}


public class MyActor extends UntypedActor{
private final DbAccess db = new DbAccess(this);
private final Auth auth = new Auth(this);

public void onReceive(Object msg){
//use the shared logic of db and auth wherever needed
}
}

(One nasty issue here is that the constructor of MyActor is sending this 
before it's fully constructed, so it's probably better to move the 
initialization of dependencies to preStart, but I kept the code shorter 
here)

There are exceptions to this rule.

For example, if you wanted to override any of the UntypedActor methods 
(e.g. we do that for one-off actors so they will stop in case of an 
unhandled message), you'd have to use inheritance, so in some cases we do 
use that, but we try to keep it down to as few levels of it as possible.


Another alternative if you're using Java 8 AND your methods don't rely on 
state, is to use interfaces with default methods,as a poor man's 
replacement for Scala traits.

In that case, if you wanted to rely on running inside an actor you could 
require actors to implement a single interface that exposes the this 
pointer and then add as many interfaces with default methods as you wish.
For example:

public interface ActorExposer {
public UntypedActor getActor();
}

public interface DbUser extends ActorExposer{
//methods for DB access
public default ...
}

public class Auth extends ActorExposer{
//methods for Authentication
public default ...
}


public class MyActor implements DbUser, Auth{
public void onReceive(Object msg){
//use the shared logic of db and auth whereever needed
}

@Override
public UntypedActor getActor() {
return this;
}
}




Finally, for asynchronous paths we simply use more actors, but I assume 
that was already obvious to you and you were asking about the previous part 
of my answer.
I hope this helps.


Adam.

  

On Tuesday, January 13, 2015 at 10:46:45 PM UTC+2, Alon Goldshuv wrote:

 (newbie question)

 Hi,

 I'd like to write a set of Actors that behave very similarly, however have 
 a few differences as well. 
 In plain java world I'd write an Abstract parent class that includes all 
 of the shared behavior, have each child class extend it, and override only 
 the class methods that differ from the abstract class implementation.

 I'm not sure how to do it in Akka - Java. I've seen a very similar 
 question and a really nice answer here 
 http://stackoverflow.com/questions/17383827/how-do-i-best-share-behavior-among-akka-actors,
  
 but it's using scala, and scala traits.

 My initial thought was something like:

 public abstract class MyParentActor(...) extends UntypedActor {
 ...
 few class methods and their implementations
 }


 public class MyChildActor1(...) extends MyParentActor {
 super(...);
 some class methods

 public void onReceive(msg) {
   use class or MyParentActor methods
 }
 }

 Is that a good idea? will that work?

 BTW, since the project has yet to start, I'm not tied to a specific Akka 
 version, so I assume 2.3.8.

 Thanks in advance!
 Alon.



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

Re: [akka-user] [cluster] minimum number of members and cluster-singleton

[Adam Warski]

Something like downing all members if there's no quorum? I was thinking 
about that, but there are two problems:
- under the current cluster specification, is there a way to resurrect a 
node? Wouldn't smarter downing require you to add a new state, something 
like suspended (waiting for enough members to be in the same state)?
- wouldn't this be too global? a per-singleton setting doesn't impact the 
cluster as a whole, you can have in a single cluster some services which 
require a quorum, and others which can operate even in a split brain 
scenario

If I get some free time I'd be happy to work on the issue, I assume master 
is a good starting point?

Adam

On Friday, January 2, 2015 3:58:37 PM UTC+1, Patrik Nordwall wrote:

 Hi Adam,

 We have been thinking that this should be handled with a smarter downing 
 strategy, but since it would be easy to implement it in the singleton 
 manager as you propose I think we should consider it. It has already been 
 requested in issue: https://github.com/akka/akka/issues/16535

 Cheers,
 Patrik

 On Tue, Dec 30, 2014 at 1:07 PM, Adam Warski ad...@warski.org 
 javascript: wrote:

 Hello,

 I was wondering how to avoid split-brain issues when using a cluster 
 singleton and automatic downing.
 Wouldn't it make sense to add a min-nr-of-members setting to the 
 singleton? That is, the singleton wouldn't start unless there's a given 
 number of members in the cluster online. That would solve the split brain 
 problem with singletons.

 I know there is the per-role min-nr-of-members setting, which impacts 
 the startup of the cluster as a whole, and maybe this could be re-used 
 (currently if nodes start up, and then some die (leaving a smaller number 
 than the setting alive), the singleton starts up anyway).

 Adam

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




 -- 

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  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] [akka-streams] Duplicator example from the docs

[Adam Warski]

Ok, if there's only one ball, that answers the question. Thanks! :)

Adam

On Thursday, January 1, 2015 10:00:27 AM UTC+1, Akka Team wrote:

 Hi Adam,

 PushPull stage callbacks are never concurrent. Also, if a stage calls 
 ctx.Push then it will receive eventually an onPull, and whenever it calls 
 ctx.pull, it will receive an onPush eventually (of course completion events 
 can come at any time).

 I'm wondering if there are any guarantees on the order of calling onPush() 
 and onPull()? For example, that onPush() won't be called twice in 
 succession, but that onPush() and onPull calls are interleaved? Otherwise 
 we may end up not duplicating elements (since we only remember the last 
 one).


 You can imagine a series of stages like a pipe and a bouncing ball. When 
 receiving onPush() the ball just bounced into that segment of the pipe. If 
 you call ctx.push as a response to this, then the ball just continues 
 downwards. If you call ctx.pull, then it will bounce back upwards. There is 
 only one ball (unless you use DetachedOps but they are an advanced 
 concept).

 Currently there is no exposed API to fuse multiple operations into such a 
 synchronous pipeline so all stages will run in a separate actor, but that 
 does not change their behavior (a single stage in an actor is actually 
 three stages, two boundary ones that talk to the actor, and your stage 
 sandwiched in-between) so the above mental model works.

 These stages are completely unbuffered and there is only one activated 
 stage at a given time (in a given synchronous island).

  


 I guess this depends if there is any buffering around a custom 
 push-pull-stage, but I would expect it to have a default buffer of awaiting 
 elements?


 There is never an implicit buffer there, unless you put your own explicit 
 buffering stage.

 -Endre
  


 Adam

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




 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
  

-- 
  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] [cluster] minimum number of members and cluster-singleton

[Adam Warski]

Hello,

I was wondering how to avoid split-brain issues when using a cluster 
singleton and automatic downing.
Wouldn't it make sense to add a min-nr-of-members setting to the 
singleton? That is, the singleton wouldn't start unless there's a given 
number of members in the cluster online. That would solve the split brain 
problem with singletons.

I know there is the per-role min-nr-of-members setting, which impacts the 
startup of the cluster as a whole, and maybe this could be re-used 
(currently if nodes start up, and then some die (leaving a smaller number 
than the setting alive), the singleton starts up anyway).

Adam

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: [streams 1.0-M1]

[Adam Warski]

Done, issue added: https://github.com/akka/akka/issues/16547

Adam

On Monday, December 15, 2014 12:16:17 PM UTC+1, Björn Antonsson wrote:

 Hi Adam,

 Yes, that seems to bit awkward. And yes that part of the TCP API also 
 feels a bit backwards. I think that we need to revisit these things when 
 designing the bidirectional flows 
 https://github.com/akka/akka/issues/16416 that more properly represent 
 a TCP connection in this case. But for now I think that there is no nice 
 workaround. Maybe we still would need that kind of source though. Would you 
 mind opening a ticket?

 B/

 On 11 December 2014 at 11:34:57, Adam Warski (ad...@warski.org 
 javascript:) wrote:

 Seems I forgot to actually write the title, sorry ;) It should be sth like 
 No-element never-completed source 

 Adam

 On Thursday, December 11, 2014 11:33:42 AM UTC+1, Adam Warski wrote: 

 Hello, 

 I'm migrating to the latest streams, the new client-server stream tcp 
 flow does require some mind-bending (switching from req-response to a flow 
 both on the client and the server), but I got it working except one thing I 
 don't like. 

 I have a client (Sender) which sends out messages to the server (Broker), 
 and these messages are then forwarded to an actor-sink. There are no 
 replies. Still, I need some kind of Source to complete the server-side 
 flow. Moreover, I'm using stream-completion to detect that the server 
 (Broker) died or otherwise disappeared. So I need a Source that is never 
 completed and has no elements. Currently I'm using 
 FutureSource(Promise().future), but this seems like a bit of a hack (though 
 the good side is it's working ;) ).

 The code is here:
  
 https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34
  
 Any thoughts? :)

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


 -- 
 Björn Antonsson
 Typesafe http://typesafe.com/ – Reactive Apps on the JVM
 twitter: @bantonsson http://twitter.com/#!/bantonsson



-- 
  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] [streams 1.0-M1]

[Adam Warski]

Hello,

I'm migrating to the latest streams, the new client-server stream tcp flow 
does require some mind-bending (switching from req-response to a flow both 
on the client and the server), but I got it working except one thing I 
don't like. 

I have a client (Sender) which sends out messages to the server (Broker), 
and these messages are then forwarded to an actor-sink. There are no 
replies. Still, I need some kind of Source to complete the server-side 
flow. Moreover, I'm using stream-completion to detect that the server 
(Broker) died or otherwise disappeared. So I need a Source that is never 
completed and has no elements. Currently I'm using 
FutureSource(Promise().future), but this seems like a bit of a hack (though 
the good side is it's working ;) ).

The code is here:
https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34

Any thoughts? :)

Adam

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [streams 1.0-M1]

[Adam Warski]

Seems I forgot to actually write the title, sorry ;) It should be sth like 
No-element never-completed source

Adam

On Thursday, December 11, 2014 11:33:42 AM UTC+1, Adam Warski wrote:

 Hello,

 I'm migrating to the latest streams, the new client-server stream tcp flow 
 does require some mind-bending (switching from req-response to a flow both 
 on the client and the server), but I got it working except one thing I 
 don't like. 

 I have a client (Sender) which sends out messages to the server (Broker), 
 and these messages are then forwarded to an actor-sink. There are no 
 replies. Still, I need some kind of Source to complete the server-side 
 flow. Moreover, I'm using stream-completion to detect that the server 
 (Broker) died or otherwise disappeared. So I need a Source that is never 
 completed and has no elements. Currently I'm using 
 FutureSource(Promise().future), but this seems like a bit of a hack (though 
 the good side is it's working ;) ).

 The code is here:

 https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34

 Any thoughts? :)

 Adam


-- 
  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] Maven, scala, akka - version mismatch

[Adam]

Try running mvn dependency:tree (before and after commenting out).
It will show you exactly how you get each library. 
Most probably you're getting akka 2.3.X for scala 2.11 as a transitive 
dependency.

-- 
  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] Reactive actor-actor communication

[Adam Warski]

 sorry it took my a while to get to this email - been consuming the least 
 responded / oldest email from the list throughout the week, not sure it 
 this worked well or not yet... :-)

no problem, it's open-source, no SLAs ;)
 

 By the way - isn't dropping demand messages a problem also in the current 
 remote-streams implementation?

 There is no remote akka streams yet.
 If you mean tcp then the demand is just generated by the socket - not 
 through passing tokens over the network.

ah I see, turns out I should have studied the code carefully (and TCP as 
well probably ;) )
 

 Right, well, originally I was wondering if Akka could replace 
 Kafka+Zookeeper's message streams (which can be used to implement the 
 scenario above: where there's a pool of producers, and a pool of consumers, 
 all potentially on different hosts, and using Kafka they can stream 
 messages reliably). With Kafka's delivery methods you bind each consumer to 
 a number of partitions, so it would be as you describe, kind of 
 point-to-point streams, which get re-balanced when a node goes down. 

 Going this route, there could be a cluster-singleton service which 
 assigns B-actors to A-actors, and creates streams between those two. These 
 could be the reactive message streams from above. And to solve the 
 demand-splitting problem (when a B has two As assigned), there could be 
 simply more consumer-actors then producer-actors.

 This sounds like a very interesting use case.
 Would be awesome if you could tinker around it. 

Random fact is that Kafka is *so much used everywhere* that it definitely 
 would find users/contributors I think :-)

great, always good to validate ideas :)

thanks,
Adam 

-- 
  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] Reactive actor-actor communication

[Adam Warski]

 By the way - isn't dropping demand messages a problem also in the current 
 remote-streams implementation?

 There is no remote akka streams yet.
 If you mean tcp then the demand is just generated by the socket - not 
 through passing tokens over the network.


So as I understand back-pressure is implemented as described here: 
http://doc.akka.io/docs/akka/2.3.7/scala/io-tcp.html (with propagation to 
the writer side by using TCP buffers), right? If the subscriber doesn't 
generate demand, this will result in suspending reading from the socket?

Adam
 

-- 
  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] Reactive actor-actor communication

[Adam Warski]

I opened GH issues and I see Konrad beat me to 
it: https://github.com/akka/akka/issues/16348 :)

Adam

On Wednesday, November 19, 2014 8:36:41 AM UTC+2, rkuhn wrote:

 Hi Adam,

 your initial point of creating a growing (and maybe thundering) herd of 
 retries is a good one and it would be better if we would limit the number 
 of messages to be resent. Could you open a ticket for that?

 Thanks,

 Roland 

 Sent from my iPhone

 On Nov 18, 2014, at 04:08, Adam Warski ad...@warski.org javascript: 
 wrote:

 Hey,

 It would be more complicated to replace AtLeastOnceDelivery with your 
 demand-driven proposal - the entire point of ALOD is that it fights back 
 the fact that messages can get lost and nodes can go down.
 Effectively what you're proposing is to switch from re-sending until I 
 get confirmations (push) to pulling all the time (pull), the catch here 
 is – *what if the demand messages get lost?*, so you'd have to add 
 re-delivery of the demand tokens themselves anyway.


 True, the demand can get lost as well. Hmm... and that would be in fact a 
 problem of any reactive stream between remote actors. This would make 
 things more complex, but still doable, in a peer-to-peer setting at least 
 (without routers). And would help with the potential flooding of the 
 destination when it comes back after being absent for a longer time. But as 
 I understand it's not complete non-sense ;) 

 By the way - isn't dropping demand messages a problem also in the current 
 remote-streams implementation?
  

 Also imagine that you're trying to send M1 to A1, the A node goes down, 
 it restarts. You could keep redelivering the M1 message, which would 
 trigger the *starting* of the A1 actor (it could be persistent actor, in 
 a shard, which starts when it gets a message),
 then the push mode of ALOD will revive this A1 guy and deliver the M1 
 message. This would not work in a just pull based model - you'd have to 
 revive *everyone* on A after a restart just in order to start asking 
 around in the cluster if someone didn't have a message they wanted to send 
 to these A# actor – where as with the retry (push) model, they are just 
 started whenever there really is some message to be delivered to them, no 
 need to start them and ask around.


 Sure, as we move away from peer-to-peer to more actors things do get more 
 complex, but then, if you want to have back-pressure, you need some kind of 
 feedback. I'd see it as a tradeoff - either lazily started actors, or 
 backpressure.

 If the sharded actors are aggregate roots, for example, then lazy loading 
 makes perfect sense. But if these are workers, of which there are a couple 
 per host, then this wouldn't be a problem. Just depends on the type of work 
 they are supposed to do.
  

 I'd also like to make sure what you mean by reactive when you use it in 
 this proposal – I assume you mean the *reactive*-streams reactive, as 
 in abides to the reactive streams protocol, and akka-streams of course 
 drive those using messaging (in most cases).


 Yes, reactive streams, mental shortcut :)
  

 If so, then yes – we do plan to support reactive-streams over the 
 network, in our case those will be actor's and messages of course, and yes, 
 we'll need to implement a reliable redelivery transport for those messages.


 Great to hear :)
  

 We're not there yet, but we definitely will cross that bridge when we get 
 there :-)

 Let's move on to the Router example;
 Well, this is pretty much what we deal with nowadays with elements like 
 Broadcast 
 https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/javadsl/FlowGraph.scala#L165
  
 / Balance 
 https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fakka%2Fakka%2Fblob%2Frelease-2.3-dev%2Fakka-stream%2Fsrc%2Fmain%2Fscala%2Fakka%2Fstream%2Fjavadsl%2FFlowGraph.scala%23L209sa=Dsntz=1usg=AFQjCNFSrMR25-LKR9NaD5WOGaYkn7az4g
  and *FlexiRoute* 
 https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fakka%2Fakka%2Fblob%2Frelease-2.3-dev%2Fakka-stream%2Fsrc%2Fmain%2Fscala%2Fakka%2Fstream%2Fjavadsl%2FFlexiRoute.scalasa=Dsntz=1usg=AFQjCNF5wRj3RGifRFHYYzVy6qJr7Fb17A
 .
 Especially FlexiRoute should be of interest for you (in this example).


 I'm wondering how many more functionalities are there in the code 
 undiscovered ;) But that will change when the docs are there I guess :)
  

 As for the last proposal... I think it's either missing some details, or 
 is wishful thinking.
 How would you without a central entity be able to guarantee that you're 
 properly balancing values among all the B side actors?
 If you can just peer to peer between then you could simply just use 
 point-to-point streams, and if that's not doable, there will be some form 
 of router anyway doing the routing between A and B actors.


 Right, well, originally I was wondering if Akka could replace 
 Kafka+Zookeeper's message streams (which can be used to implement the 
 scenario above: where there's a pool

Re: [akka-user] Testing per-request child creation

[Adam]

It's a matter if opinion and I risk stating the obvious, but my (unoriginal) 
rules of thumb are: 

Updates to internal state are out of scope for tests. Sometimes when something 
is not testable, it's for a good reason - you're code should simply be 
modified. This is one of those cases.

Adding introspection methods for tests purposes only is a bad practice, but if 
you already have such a method that is part of the public interface of the 
component under test, then it's legitimate to use it.

For cases where this is not the case you can consider encapsulating the state 
in a separate object that can be passed into the component under test (although 
doing this for something as simple as a timestamp does sound a bit too much).

Alternatively for some cases where the actor can be said to give message based 
access to some encapsulated state, I extract that to a separate class that can 
be unit tested separately.

-- 
  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] Reactive actor-actor communication

[Adam Warski]

 problem (when a B has two As assigned), there could be 
simply more consumer-actors then producer-actors.

Thanks!
Adam

-- 
  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] Reactive actor-actor communication

[Adam Warski]

Hello,

I was looking at AtLeastOnceDelivery and what problems it might have when 
the destination actor dies or becomes slow. Apart from the obvious 
out-of-memory which would eventually happen (and which can be solved with a 
smarter ALOD version which flushes excess data to disk), there's also the 
problem of an increasing load of messages when the destination is 
unavailable: every new message is retried, and retried, and retried, and 
this adds up ... wouldn't it be a perfect place for a reactive message 
stream?

Are reactive message streams between actors anything that has been 
considered? (I know that for sure it's not implemented, but just wondering 
in general, if it makes sense.) This could be especially useful if the 
actors are on separate nodes - reactive remoting.

One problem here would be handling routers. Let's say we have an A actor 
streaming messages to two B actors:

  /-- B1
A --- R --- 
  \-- B2

where R is a router. Now the router would have be smart about the demand 
coming from B1 and B2: sum the demand and return it to A, and when A sends 
messages, split them according to the earlier requests.

Going even further (and that is the original problem that I was wondering 
about), let's say we have a pool of A-actors (potentially on different 
cluster nodes using e.g cluster sharding) and a pool of B-actors (again 
potentially on different cluster nodes). The goal is to have a reliable 
message stream between the A-actors and the B-actors. The additional 
complication here is that there's no central router, so even if there was a 
reactive message stream available between any two nodes, the B-actors would 
have no idea how to split the demand between the A-actors. Or maybe the 
direction I'm heading with this is somehow wrong? :)

Adam

-- 
  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] How to Monitor akka, improving performance

[Adam]

I suspect a thread dump in this state and the akka version you're using would 
be invaluable to understanding this.

-- 
  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] Stopping a reactive stream

[Adam Warski]

 On Thu, Oct 30, 2014 at 1:43 PM, Adam Warski ad...@warski.org 
 javascript: wrote:

 There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of 
 names ;) )


 Drain is no longer there (as a name at least) and you should usually not 
 see a Subscriber ;)


It is in 0.9, but as I understand it's not in master :)
 

 How do I use broadcast, thought? I can see it can be a vertex in the 
 graph, but how to add it?


 An example:

   FlowGraph { implicit b ⇒
 val bcast = Broadcast[Int](broadcast)
 Source(List(1, 2, 3)) ~ bcast
 bcast ~ Flow[Int] ~ Sink(s1)
 bcast ~ Flow[Int] ~ Sink(s2)
   }.run()


Thanks, I'll try that.
  

 So I'll end up with sth like this:

/--- sink1 
 (output stream)
 source -- trans1 -- broadcast --
\--- sink2 (on 
 complete drain)

 Will the failure of sink1 propagate to a completion of the whole stream? 
 In theory it could continue in a crippled way (with only one branch 
 remaining).


 True, in this setup sink2 will get the termination event of source but 
 will not get the canceled event of sink1. Internally it is configurable if 
 broadcast should continue or not in this case but this is not exposed to 
 the users (it continues by default now).


So even if sink1 fails, the whole setup will continue? So using sink2 (on 
complete sink/drain) won't have any effect? Is there a way to detect errors 
in such case then?
 

 Btw, in your TCP example you don't use the inputStream of the connection, 
 if you use that stream it will give you the termination events of the TCP 
 connection (normal/error). Output stream can only say cancelled but not 
 why.


Well this application only sends data, so I don't need the input stream for 
anything.

Even supposing broadcast does work, shouldn't there be some other way to 
detect and handle failures/errors/completions? E.g. wouldn't it make sense 
to add a callback to run()? Or make run() return some kind of Future? 
Creating an artificial broadcast just to detect errors seems not optimal :)

Adam

-- 
  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] Stopping a reactive stream

[Adam Warski]

 So even if sink1 fails, the whole setup will continue? So using sink2 (on 
 complete sink/drain) won't have any effect? Is there a way to detect errors 
 in such case then?


 Sink2 will detect the failure of source, but not of sink1. Currently there 
 is no way to detect it, because most people expect the broadcast to 
 continue instead of failing. We can make it configurable though.


Right, I can imagine needing both. Similar to a one-for-one and one-for-all 
failover strategy when using actor supervisor hierarchies.

Btw. the javadoc for Broadcast currently says:  It will not shutdown until 
the subscriptions for at least two downstream subscribers have been 
established.. Why two? Shouldn't it be either one or all? :)
 

 You should be aware though that using the stream TCP you *don't* get an 
 error event from the outputStream anyway, you only get notified that it has 
 cancelled (Reactive Streams specify only cancel as an event propagated from 
 downstream to upstream), but not the reason why. See my other answer a bit 
 below before you panic :)


Would it make sense to add something to the current API which could detect 
such failures?
 

 Btw, in your TCP example you don't use the inputStream of the connection, 
 if you use that stream it will give you the termination events of the TCP 
 connection (normal/error). Output stream can only say cancelled but not 
 why.


 Well this application only sends data, so I don't need the input stream 
 for anything.


 This is not true, you always need to connect something to the input 
 stream, because it is the thing that carries the termination events of the 
 *TCP 
 stream pair* -- i.e. failures in outputs will be also reported on this 
 channel.

 You don't need to do anything with the input data though, you can just 
 attach an OnComplete Drain/Sink (whatever it is named in that version ;) ), 
 that will discard all data anyway, but will not clog the inbound TCP 
 buffers even if the remote part happens to send things, and you will get 
 the TCP termination events in the callback you provided to OnComplete


Ok, that's in fact much nicer, I didn't like the approach of broadcasting 
just to detect errors :). I'll try that in the evening.
 

 Even supposing broadcast does work, shouldn't there be some other way to 
 detect and handle failures/errors/completions? E.g. wouldn't it make sense 
 to add a callback to run()? Or make run() return some kind of Future? 
 Creating an artificial broadcast just to detect errors seems not optimal :)


 There is a common misconception here. Imagine a setup like this:

   inputFile - someProcessing - outputFile

 Now imagine that we provided an API that gives a completion future after 
 you call run(). Now if that future completes, would that mean that writing 
 to the file finished? Unfortunately no, since the completion of a Reactive 
 Streams means that no elements in flight anymore and everyone is aware of 
 that, but this does not imply that all the buffers of the outputFile writer 
 has been flushed and the file has been closed.

 This is exactly why Akka Streams provide Sinks (formerly Drains) that can 
 return a completion Future (or whatever they want to return) of their own 
 that is completely library dependent -- for example a file writer Sink can 
 give a Future that represents the event while the file has been completely 
 closed.


So each sink should provide a sink-dependent way of letting the user know 
when things are done or cancelled. Doesn't it mean that there should be 
a way to provide a callback or sth like that when creating the specific 
Subscriber, here it's implemented by the TCP extension? E.g. a Future or 
similar as part of the binding: StreamTcp.OutgoingTcpConnection?

Adam 

-- 
  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] Stopping a reactive stream

[Adam Warski]

Ok, so getting closer, seems to work :) Thanks a lot for the help.

On the sender side I added a separate flow for the input stream, attached 
an on complete drain and I get the callback. One small thing, even if I 
kill the other side of the connection, the callback contains a Success(()).

On the receiver side I added the forking (broadcast), and I'm getting the 
callback when the other side is killed.
 

 Doesn't it mean that there should be a way to provide a callback or sth 
 like that when creating the specific Subscriber, here it's implemented by 
 the TCP extension? E.g. a Future or similar as part of the binding: 
 StreamTcp.OutgoingTcpConnection?


 The input stream conveys all the information you need about closing 
 events, I don't see the need currently for a side-channel. We prefer to 
 keep as much as possible in-stream and not out-of-stream. Since TCP is a 
 stream in itself it works quite well, unlike with the file example I had 
 where there is a pure sink. That said, we might add more functionality if 
 needed but the design goal is to keep these external signals minimal.


Sure, this makes sense. Having as little of an additional protocol as 
possible is certainly nice. Though the fact that a socket died doesn't 
always require protocol support (I mean, often you will know that a socket 
isn't working without sending special pings or such). So this could get 
exposed to the user.

Adam

-- 
  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] Stopping a reactive stream

[Adam Warski]

Sure :) I'm using streams 0.9, scaladsl2 and I want to add failure 
detection to that:

https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Sender.scala

Adam

On Thursday, October 30, 2014 12:04:23 PM UTC+1, Akka Team wrote:

 Hi Adam,


 I'm not running Windows (MacOS), but how could these signals be handled? 
 I was looking for some handlers in the value returned by run() (e.g. 
 onComplete, onError), but it seems not much is there :)


 Which version of Akka Stream are you using and which version of the 
 scaladsl? How does your pipeline look like, what is the sink element (the 
 thing in which you pipe TCP into).

 In general, a code snippet would help a lot.

 -Endre
  


 Thanks,
 Adam

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




 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
  

-- 
  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] Stopping a reactive stream

[Adam Warski]

There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of 
names ;) )

How do I use broadcast, thought? I can see it can be a vertex in the graph, 
but how to add it?

So I'll end up with sth like this:

   /--- sink1 (output 
stream)
source -- trans1 -- broadcast --
   \--- sink2 (on 
complete drain)

Will the failure of sink1 propagate to a completion of the whole stream? In 
theory it could continue in a crippled way (with only one branch 
remaining).

Thanks!
Adam

On Thursday, October 30, 2014 1:22:41 PM UTC+1, Akka Team wrote:

 Hi Adam,

 You can use broadcast to split out the stream going into the Sink, and 
 then attach to that side of the graph an OnCompleteSink which takes a 
 function callback: Try[Unit] ⇒ Unit which is called during normal and 
 failure termination.

 -Endre

 On Thu, Oct 30, 2014 at 12:31 PM, Adam Warski ad...@warski.org 
 javascript: wrote:

 Sure :) I'm using streams 0.9, scaladsl2 and I want to add failure 
 detection to that:


 https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Sender.scala

 Adam

 On Thursday, October 30, 2014 12:04:23 PM UTC+1, Akka Team wrote:

 Hi Adam,


 I'm not running Windows (MacOS), but how could these signals be 
 handled? I was looking for some handlers in the value returned by run() 
 (e.g. onComplete, onError), but it seems not much is there :)


 Which version of Akka Stream are you using and which version of the 
 scaladsl? How does your pipeline look like, what is the sink element (the 
 thing in which you pipe TCP into).

 In general, a code snippet would help a lot.

 -Endre
  


 Thanks,
 Adam

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




 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
  
  -- 
  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 javascript:.
 To post to this group, send email to akka...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam
  

-- 
  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] Stopping a reactive stream

[Adam Warski]

Hello,

is there a way to stop a reactive running reactive stream, e.g. by making 
it watch some other actors, and when they are dead, die as well?

This might or might not be associated with the components of the stream 
itself; in my current scenario I have a sink which is a reactive tcp 
connection. I don't seem to be getting any errors (at least logged) by 
shutting down the other side of the tcp connection, however I do get 
outside errors, from the cluster/remoting watch - so I could use that to 
restart the whole thing, if only I could make some supervisor hierarchy 
for the stream.

-- 
Thanks,
Adam

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [Java 2.3.x] Default message behaviors?

[Adam]

One easy way is to extend UntypedActor, override whatever methods you need 
with final methods and provide your own callback methods for overriding by 
sub classes.
The slightly messy part of this is that you’ll be forced to provide 
callback method names with different names (e.g. onResolverReceive).

A nicer but slightly more complex solution is to use something like AspectJ 
with load time weaving and simply mark classes for which you need such 
defaults with an annotation, interface, or some coding convention.


On Monday, October 20, 2014 10:34:44 PM UTC+3, Chanan Braunstein wrote:

 Hello,

 Is it possible to define a base class for actors that will provide some 
 default behaviors? For example I create a MyAbstractActor that handles 
 MyMessage type. Someone on my team can then extend that class and handle 
 some other types as well. Somewhat like AbstractPersistentActor handles 
 Persistent messages, but in Java and hopefully without implementing all of 
 Actor which at a glance seems like AbstractPersistentActor is doing.

 Thanks,
 Chanan


-- 
  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] Realtime (as in Electronics) processing in Akka and Garbage Collection's Effect to It

[Adam Retter]

I have not had time to watch this yet, but perhaps it may be of some
interest - https://vimeo.com/105888905

On 17 October 2014 08:39, Koray Al hecatom...@gmail.com wrote:
 Hello All,

 Our application is nearly offline, it doesn't need to communicate with
 remote servers etc. The only obligation they have is to communicate with the
 hardware that are in the same gigabit network in realtime. So the load is
 nearly at the same level all the time. We also already have more memory than
 it needs. (in fact currently the application is using %8 of the computer
 memory at most)

 I have checked out my application with jHiccup (which Adam suggested)
 running for a day and it seems that the highest hiccup duration is 65
 milliseconds. It is acceptable for my application ( but it will not be, if I
 try to implement the realtime part I was asking for ) A friend of mine also
 suggested checking out the garbage collection suggestions for Apache Kafka
 and Twitter Storm. ( https://gist.github.com/mrflip/5958028 ) I will monitor
 the system with suggestions from there.

 After watching Konrad's link, I am now sure that I am way over my head :)
 But I think using optimizations suggested by experts will surely help.

 It looks like I will have to use C++ for that kind of realtime applications,
 but I will resist as long as I can :)

 Regards,
 Koray

 On Thursday, October 16, 2014 3:57:42 PM UTC+3, Alec Zorab wrote:

 I'm not sure I'd say it was the *most* important factor - if you're
 spending a lot of time talking to a database or waiting for packets to cross
 the atlantic then you may have other problems to contend with, but certainly
 at the 5ms scale, GC can have a very significant impact.

 GC monitoring and tuning on the jvm is an art unto itself - google's
 probably the best way to familiarise yourself with it, but if you just want
 to get  a quick and dirty feel for what's going on, the VisualGC plugin for
 VisualVM is useful.

 On 16 October 2014 13:30, Koray Al hecat...@gmail.com wrote:

 @Alec

 So when 5ms is the target, you are saying that the GC becomes the most
 important factor for the system's performance. Do you have any suggestion
 (book/website etc.) for me to check out for this matter? I have my
 application currently running in a high traffic environment and I would love
 to monitor GC pauses periodically if I knew how :)

 @Adam

 Thank you for the suggestion, I also came across similar JVMs but the
 cost seems to be unapplicable for me since most of my applications do not
 run in a central server, instead it runs on a lot of nodes.

 @Conrad

 Thank you for the link, this is exactly what I am looking for since I
 have no idea what to check for my system's performance. In the meantime I
 was checking out Kamon since my application generates and kills a lot of
 actors and I need a way to monitor actor counts, transaction times etc.

 I will check out all your suggestions.

 Regards,
 Koray


 On Wednesday, October 15, 2014 3:24:53 PM UTC+3, Akka Team wrote:

 Hi Koray,
 I concur with the other guys – these kinds of skills are very specific.
 It's certainly doable, and there's loads of companies using both the JVM
 and/or Akka for these kinds of systems, but it requires a lot of thinking /
 monitoring / tweaking to get these super high performance apps.
 Here's a talk from the Twitter guys I really liked which shows a bit of
 the resources and techniques one has to apply when building such apps:
 Twitter-Scale Computing with OpenJDK (youtube).

 These topics are the fun and interesting part, so you're in for a ride -
 enjoy it. :-)

 --
 Konrad

 Akka Team
 Typesafe - The software stack for applications that scale
 Blog: letitcrash.com
 Twitter: @akkateam

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



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http

[akka-user] Realtime (as in Electronics) processing in Akka and Garbage Collection's Effect to It

[Adam]

There is also an option of trying the Zing JVM from Azul. It's not free, but 
depending on your case, it might end up being cheaper in the overall, assuming 
it does what they claim - I've never used it myself, only talked to other 
people who were using it.

Also it's possible for some applications to be written in a way that minimize 
the allocation rate. Unfortunately I think this doesn't work well with 
immutability and it can also mean just as much extra effort as writing in a 
different language.

If you do stay on the JVM, Azul also published a free and very useful tool 
called jhiccup (for obviius reasons  ).

-- 
  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] Akka Cluster Metrics- Node Wise

[Adam]

You cannot have separate cpu and heap metrics for nodes within the same JVM.
OSGI won't help either - it mostly achieves containment through complex class 
loaders.

You could sort of have an approximiation of CPU consumption per node by summing 
up the thread cpu consumption for the related dispatcher threads, but that 
would disregard all implicit CPU, like that of GC.

Heap monitoring is yet even harder. The JVMTI API provides some basic 
facilities to acheive that, but the overhead is likely to kill your 
application. Plus it's a huge amount of work, so you'd be better off paying for 
a commercial monitoring product (which still doesn't resolve the issue of 
overhead and probably doesn't give you exactly what you want).

Much cheaper to run several JVMs...

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: combining receive pfs - am I being stupid here?

[Adam]

I think you can assume this is some kind of bug.
According to the definition of Receive 
http://doc.akka.io/api/akka/2.3.6/?_ga=1.83289750.1264712766.1405541415#akka.actor.Actor$@Receive=PartialFunction[Any,Unit]
 
it's equivalent to PartialFunction[Any, Unit] and yet, the following 
generates no warning (changed the declared return type of y):

class TestPF extends Actor {

  val x: Receive = {
case hi = sender ! hello
  }

  val y: PartialFunction[Any, Unit] = {
case bye = sender ! farewell
  }

  def receive = x orElse y

}

So you should probably open a Scala bug for this, if there isn't already 
one.

On Wednesday, September 24, 2014 1:30:57 AM UTC+3, Tim Pigden wrote:

 seems to be to do with the Xlint option


 On Tuesday, September 23, 2014 11:16:51 PM UTC+1, Tim Pigden wrote:

 sorry meant to add - yes with or without { } it has the same and just 
 changing now to 2.3.6 it makes no different

 On 23 September 2014 23:15, Tim Pigden tim.p...@optrak.com javascript:
  wrote:

 2.11.2 (akka 2.3.4)

 scalacOptions := Seq(-feature, -deprecation, -encoding, utf8, 
 -Xlint)

 On 23 September 2014 21:26, Adam adam...@gmail.com javascript: 
 wrote:

 Interesting.
 Which Scala version are you using?

 I've copied your code into a Scala project I have that uses Scala 
 2.11.2 (with akka 2.3.6) and I get no warnings.
 Also the IDE (Intellij) correctly shows that receive is of type 
 PartialFunction[Any,Unit].

 Have you tried modifying it to:

 def receive: Receive = { x orElse y }

 ?

 I would assume that should cause type inference to be skipped and 
 therefore also make the warning go away, like in the previous answer.


 On Tuesday, September 23, 2014 7:29:08 PM UTC+3, Tim Pigden wrote:

 The following example:

 class TestPF extends Actor {

   val x: Receive = {
 case hi = sender ! hello
   }

   val y: Receive = {
 case bye = sender ! farewell
   }

   def receive = { x orElse y }

 }

 gets a warning
 Warning:(18, 28) a type was inferred to be `Any`; this may indicate a 
 programming error.
   def receive = { x orElse y }
^

 Am I doing something wrong? I thought this was the intended use 
 pattern. Can I make these warnings go away?

  -- 
  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/0rkUCQxru5I/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 akka-user+...@googlegroups.com javascript:.
 To post to this group, send email to akka...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 -- 
 Tim Pigden
 Optrak Distribution Software Limited
 +44 (0)1992 517100
 http://www.linkedin.com/in/timpigden
 http://optrak.com
 Optrak Distribution Software Ltd is a limited company registered in 
 England and Wales.
 Company Registration No. 2327613 Registered Offices: Suite 6,The 
 Maltings, Hoe Lane, Ware, SG12 9LR England 
 This email and any attachments to it may be confidential and are 
 intended solely for the use of the individual to whom it is addressed. Any 
 views or opinions expressed are solely those of the author and do not 
 necessarily represent those of Optrak Distribution Software Ltd. If you are 
 not the intended recipient of this email, you must neither take any action 
 based upon its contents, nor copy or show it to anyone. Please contact the 
 sender if you believe you have received this email in error.
  



 -- 
 Tim Pigden
 Optrak Distribution Software Limited
 +44 (0)1992 517100
 http://www.linkedin.com/in/timpigden
 http://optrak.com
 Optrak Distribution Software Ltd is a limited company registered in 
 England and Wales.
 Company Registration No. 2327613 Registered Offices: Suite 6,The 
 Maltings, Hoe Lane, Ware, SG12 9LR England 
 This email and any attachments to it may be confidential and are intended 
 solely for the use of the individual to whom it is addressed. Any views or 
 opinions expressed are solely those of the author and do not necessarily 
 represent those of Optrak Distribution Software Ltd. If you are not the 
 intended recipient of this email, you must neither take any action based 
 upon its contents, nor copy or show it to anyone. Please contact the sender 
 if you believe you have received this email in error.
  


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

[akka-user] foreach in akka-streams 0.7

[Adam Warski]

Hello,

I recently migrated some code from old reactive streams to 0.7, and as part 
of that I replaced .foreach with a combination of .map (where the function 
resulted in Unit) and .consume().

Roland in a tweet 
(https://twitter.com/rolandkuhn/status/512143662676193280) says that: 
foreach is a Sink type now, which I don't really understand :). Is there 
some different way to implement foreach? (the foreach usage I have is to 
handle connections from stream-tcp)

Thanks,
Adam

-- 
  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] foreach in akka-streams 0.7

[Adam Warski]

Got it, thanks! Updated the code :)

Adam

On Wednesday, September 17, 2014 2:50:23 PM UTC-7, Konrad Malawski wrote:

 Hello Adam,
 yes, there is: .withSink(ForeachSink(el = ).run()
 ​
 The sink also holds a future which you can watch for completion, see: 
 http://doc.akka.io/api/akka-stream-and-http-experimental/0.7/?_ga=1.32419708.350209094.1396869304#akka.stream.scaladsl2.ForeachSink

 Hope this helps!

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

 http://typesafe.com
  

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Handle legacy blocking IO (InputStream/OutputStream)

[Adam]

(by akka.io, I meant the IO package of akka 
http://doc.akka.io/docs/akka/2.3.5/scala/io.html, of course...)

On Tuesday, September 2, 2014 4:06:56 PM UTC+3, Adam wrote:

 Hi,

 I'm not sure how using protobuf forces you to communicate in a blocking 
 manner.
 I'm also using it but over akka.io, which is modeled as actors, so it's 
 completely non blocking and works in exactly the same way as the rest of my 
 application does.




 On Tuesday, September 2, 2014 11:44:27 AM UTC+3, Andy Bean wrote:

 I'm new to akka and have a problem when handling blocking IO. I need to 
 integrate the protobuf library that is reading/writing data using standard 
 java InputStream/OutputStream in a blocking way.

 In my case I open a network connection using a SocketChannel and create 
 an InputStream and an OutputStream from it. Now I need to read and write 
 data concurrently. My first approach was to have a Future for reading data 
 in an blocking way and sending it to the enclosing actors. Writing is done 
 in a separate actor. When I receive an error I can only stop the writer but 
 not the reader.

 My structure:

 class Handler extends Actor {
  val reader: Future
  val writer: ActorRef
 }

 I'm a bit lost now because I need to handle connection failures and 
 reconnect on errors. What would be the best way to handle my situation?

 Greetings,
  Andy



-- 
  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] modifying log level at run-time

[Adam]

Hi,

One more follow up question.
When using the setting advised by the documentation for this scenario 
(http://doc.akka.io/docs/akka/snapshot/java/logging.html#SLF4J) the only 
real gap from what I need is that with akka.logLevel set to DEBUG and with 
the SLF4J binding configured to INFO, writing code like this:

 
   if (logger.isDebugEnabled()) {
  logger.error(This is an error);
}


Will cause the above error to be logged, which isn't really what I'd expect 
to happen (I'd expect nothing to be logged).

If I were to use the event bus to circumvent this, it would probably 
resolve many cases of this happening (depending on how often this code is 
reached and how often I’d be polling the configuration), but it wouldn’t 
really make this go away.
So should I really go down this road, or is this really a bug that could be 
fixed in Akka?
Or maybe this is actually an intended limitation?

-- 
  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] modifying log level at run-time

[Adam]

Hi,

I know Akka's configuration does not get reloaded at run-time (see here 
https://groups.google.com/forum/#!msg/akka-user/bQA1zJP3yOY/fBVmGfRvYUYJ).
It is however quite a common use case for logger settings to be re-loadable 
at run-time.
Is there any way to achieve this?

-- 
  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] Changing socket options from the Java API of Akka IO

[Adam]

Hi,

Is there a way to change socket options such as send  receive buffers from 
the Java API?
All I can find is the set of Scala case classes (e.g. 
http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
 
but to the best of my knowledge there is no way to use case classes from 
Java, so I'm wondering if I must create Scala wrappers that can be called 
from Java to achieve this.

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