Re: [akka-user] Older version of Akka framework

[Konrad “ktoso” Malawski]

Hi Jani,
Use your dependency management tool such as sbt, maven or gradle to
download dependencies.
They’re all hosted on maven central.

No actively maintained version of Akka is compatible with JDK6.
You can use a not-maintained version of 2.3.x though — though we strongly
discourage that since it’s ancient (2015).

Akka is a toolkit, not a framework :-)

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 14, 2017 at 16:07:22, Jani Lillkåll (jlmailer2...@gmail.com)
wrote:

  Hi !

 Is there a place to download older version of Akka framework,  that would
compile with Java JDK 1.6 ?  Thanks for any info you can give. yours
Jani
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
"Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

[akka-user] Older version of Akka framework

[Jani Lillkåll]

  Hi !

 Is there a place to download older version of Akka framework,  that would 
compile with Java JDK 1.6 ?  Thanks for any info you can give. yours   
Jani

-- 
>>  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] FSMs and Akka Streams

[Konrad “ktoso” Malawski]

Hi John,
your problem description is a bit abstract so not quite sure what to advice
there,
however: please do bear in mind that Streams do not replace Actors.
They complement them. Streams are nice for linear things,
though Actors are nice for dynamic and distributed settings.

It depends on your exact problem.

Yes, if it’s a more-or-less static processing pipeline you can model it as
a stream (akka http is for example all streams).
You can take a look at building custom GraphStages (search the docs for
that keyword).

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 11, 2017 at 11:13:32, John Antypas (janty...@busygeeks.com)
wrote:

Good evening all

I'm learning my Akka, or rather learning to do it better.  I'm looking at
writing a lightweight protocol stack.  In the old Java world, I'd write a
rather large FSM that would handle all states and events.. but that was the
old days.  I assume today, I'd want to use Akka streams.  Assume I had
something like this:

FSM-Main:
 Handles main protocol states (Connected, Setup, Authentication,
Running)
Under each state, I have an FSM just for that state.  For example, under
the Auth state, I have a sub FSM that handles the various authentication
FSM.
I assume this is legal.

Now, in streams, where does this fit in with Akka streams -- I assume each
stream element would have its own FSM?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
"Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Christopher Hunt]

Thanks Viktor, I’ve gone with your suggestion which I think is nice and 
explicit:

private val eh = Thread.currentThread().getUncaughtExceptionHandler
system.whenTerminated
  .andThen {
case _ =>
  try {
println("Exiting")
System.exit(exitStatus.getOrElse(1))
  } catch {
case se: SecurityException => 
eh.uncaughtException(Thread.currentThread(), se)
  }
  }

-- 
>>  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: Help with exception with Slick JDBC connector for MS SQL Server

[lutzh]

It doesn't really match the error message, but your "driver" entry looks a 
bit off to me - shouldn't that just be the driver class name?

I think the ";databaseName=" would be attached to the 
URL part, not the driver. And the 3 before the ";", I don't know..




On Monday, November 13, 2017 at 8:19:35 PM UTC+1, indusbull wrote:
>
> I am trying Slick (JDBC) Connector tutorial 
>  to 
> connect to MS SQL Server 2012 in my prototype Java Akka project. But I am 
> having difficulties since last few hours to connect to DB through JDBC. It 
> keeps throwing below exception - Not sure what I am missing either in 
> config or code. It is simple example.
>
> Exception:
> java.sql.SQLTransientConnectionException: slick-sqlserver.db - Connection 
> is not available, request timed out after 1001ms. at 
> com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:548) 
> at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:186) at 
> com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:145) at 
> com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:83) 
> at 
> slick.jdbc.hikaricp.HikariCPJdbcDataSource.createConnection(HikariCPJdbcDataSource.scala:14)
>  
> at slick.jdbc.JdbcBackend$BaseSession.(JdbcBackend.scala:438) at 
> slick.jdbc.JdbcBackend$DatabaseDef.createSession(JdbcBackend.scala:46) at 
> slick.jdbc.JdbcBackend$DatabaseDef.createSession(JdbcBackend.scala:37) at 
> slick.basic.BasicBackend$DatabaseDef.acquireSession(BasicBackend.scala:216) 
> at 
> slick.basic.BasicBackend$DatabaseDef.acquireSession$(BasicBackend.scala:215) 
> at slick.jdbc.JdbcBackend$DatabaseDef.acquireSession(JdbcBackend.scala:37) 
> at slick.basic.BasicBackend$DatabaseDef$$anon$3.run(BasicBackend.scala:279) 
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
> java.lang.Thread.run(Unknown Source)
>
> application.config
> slick-sqlserver {
>  profile = "slick.jdbc.SQLServerProfile$" 
>
>  db { 
>
>  dataSourceClass = "slick.jdbc.DriverDataSource" 
>
>  properties = { 
>
>   driver = 
> "com.microsoft.sqlserver.jdbc.SQLServerDriver3;databaseName=dbname" 
>   url = "jdbc:sqlserver://host:1433" 
>   user = "username" 
>   password = "password" 
>  }
>   }
> }
>
> My Code
>
> ActorSystem system = ActorSystem.create("testSystem");
> final Materializer materializer = ActorMaterializer.create(system);final 
> SlickSession session = SlickSession.forConfig("slick-sqlserver");
>
> final CompletionStage done =
>   Slick
> .source(
>   session,
>   "SELECT 1",
>   //(SlickRow row) -> new Object(row.nextInt(), row.nextString())
>   (SlickRow row) -> new Object()
> )
> .log("user")
> .runWith(Sink.ignore(), materializer);
>
> done.whenComplete((value, exception) -> {
>   session.close();
>   system.terminate();
> });`
>
>

-- 
>>  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] Streaming proxy/tunel on top of akka-http

[Jozsef Zsido]

You are completrly right. I have did something differenly somewhere when I 
tested last time with browser. My code also works fine without the test 
code.
Thank you very mutch!

On Monday, November 13, 2017 at 9:28:22 PM UTC+2, Jozsef Zsido wrote:
>
> yes, I try all the time with real browser. The code blows up the memory 
> when I download a 2GB file and try to stream it from one response to another
>

-- 
>>  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] Streaming proxy/tunel on top of akka-http

[Jozsef Zsido]

yes, I try all the time with real browser. The code blows up the memory 
when I download a 2GB file and try to stream it from one response to another

-- 
>>  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: Examples for using Akka Http in streaming fashion?

[jim]

A little late to the party, but here's an example program that does several 
kinds of streaming using akka-http:

https://github.com/ludflu/akka-http-simple-test/blob/master/src/main/scala/WebServer.scala

Including:
1. streaming sourced http response
2. streamed response based on a streamed http request
3. a websocket flow
4. simple static response

On Monday, October 16, 2017 at 11:49:31 AM UTC-4, Harry wrote:
>
> Hi,
>
> I have been learning Akka Streams lately in a bid to use it to build a 
> utility to handle a batch scenario I have.
> I have been looking also at Akka Http also but have become a bit blocked 
> because although the documentation is quite extensive there are not many 
> examples.
>
> My use case is this:-
>
> 1. *Source* - Read a file of records (about 500k)
> 2. *Flow* - For each record, do a HTTP POST to a remote endpoint
> 3. *Sink* - For each Response, just log the outcome (success or failure)
>
> So I have something like this at high-level:-
>
> Source[ByteString, Future[IOResult]]  ->  *Flow*  ->  Sink[HttpRequest, 
> Future[IOResult]]
>
>
> I am not looking for someone to write my code for me but I am struggling with 
> putting togethor the whole flow because there are not many 
>
> examples of using the Flows that you can construct in Akka Http.
>
>
> Since I only need to hit 1 endpoint, I was thinking that the 
> [Flow](https://doc.akka.io/docs/akka-http/current/scala/http/client-side/request-level.html#flow-based-variant)
>  
>
> based variant of the Akka Http Request-Level Client-Side API would be the way 
> to go, I just need some examples to help me get started. 
>
>
> Can anyone point me in the right direction of some examples of using ither 
> the Request Level or Host Level APIs for using Akka HTTP in a streaming 
> fashion?
>
>
> Specifically, Im looking for examples of using Sources and Sinks with the 
> following Flows:-
>
>
> val hostPoolFlow = Http().cachedHostConnectionPool()
> val requestPoolFlow = Http().superPool()
>
>
>

-- 
>>  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] Help with exception with Slick JDBC connector for MS SQL Server

['indusbull' via Akka User List]

I am trying Slick (JDBC) Connector tutorial 
 to 
connect to MS SQL Server 2012 in my prototype Java Akka project. But I am 
having difficulties since last few hours to connect to DB through JDBC. It 
keeps throwing below exception - Not sure what I am missing either in 
config or code. It is simple example.

Exception:
java.sql.SQLTransientConnectionException: slick-sqlserver.db - Connection 
is not available, request timed out after 1001ms. at 
com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:548) 
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:186) at 
com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:145) at 
com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:83) 
at 
slick.jdbc.hikaricp.HikariCPJdbcDataSource.createConnection(HikariCPJdbcDataSource.scala:14)
 
at slick.jdbc.JdbcBackend$BaseSession.(JdbcBackend.scala:438) at 
slick.jdbc.JdbcBackend$DatabaseDef.createSession(JdbcBackend.scala:46) at 
slick.jdbc.JdbcBackend$DatabaseDef.createSession(JdbcBackend.scala:37) at 
slick.basic.BasicBackend$DatabaseDef.acquireSession(BasicBackend.scala:216) 
at 
slick.basic.BasicBackend$DatabaseDef.acquireSession$(BasicBackend.scala:215) 
at slick.jdbc.JdbcBackend$DatabaseDef.acquireSession(JdbcBackend.scala:37) 
at slick.basic.BasicBackend$DatabaseDef$$anon$3.run(BasicBackend.scala:279) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at 
java.lang.Thread.run(Unknown Source)

application.config
slick-sqlserver {
 profile = "slick.jdbc.SQLServerProfile$" 

 db { 

 dataSourceClass = "slick.jdbc.DriverDataSource" 

 properties = { 

  driver = 
"com.microsoft.sqlserver.jdbc.SQLServerDriver3;databaseName=dbname" 
  url = "jdbc:sqlserver://host:1433" 
  user = "username" 
  password = "password" 
 }
  }
}

My Code

ActorSystem system = ActorSystem.create("testSystem");
final Materializer materializer = ActorMaterializer.create(system);final 
SlickSession session = SlickSession.forConfig("slick-sqlserver");

final CompletionStage done =
  Slick
.source(
  session,
  "SELECT 1",
  //(SlickRow row) -> new Object(row.nextInt(), row.nextString())
  (SlickRow row) -> new Object()
)
.log("user")
.runWith(Sink.ignore(), materializer);

done.whenComplete((value, exception) -> {
  session.close();
  system.terminate();
});`

-- 
>>  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: Akka-HTTP compilation error using custom requireParam() directive

[johannes . rudolph]

Hi Evgeny,
you discovered one of the reasons for the magnet pattern. If you use 
`requireParam("param".as[Int]) { abc => ... }` then the `{ abc => }` block 
is mistaken as the implicit argument of `requireParam`. So, either you are 
ok with that and require users to use extra parentheses 
(`(requireParam("param".as[Int])) { abc => ... }`) or you use the magnet 
pattern at this level as well. You can read about the magnet pattern on the 
old spray blog (http://spray.io/blog/2012-12-13-the-magnet-pattern/) or 
just look into akka-http sources.

A better way to implement the feature would be just to use the existing 
implementation ;) and install a custom rejection handler that produces 
whatever output you would like. 
See 
https://doc.akka.io/docs/akka-http/10.0.10/scala/http/routing-dsl/rejections.html#customizing-rejection-handling
 
for how to do that.


Johannes


On Monday, November 13, 2017 at 9:22:19 AM UTC+1, Evgeny Veretennikov wrote:
>
> I developed custom generic directive, which will provide param of given 
> type, if it exists, or else reject with my custom exception.
>
> import akka.http.scaladsl.common.NameReceptacle
> import akka.http.scaladsl.server.Directives._
> import akka.http.scaladsl.server.directives.ParameterDirectives.
> ParamDefAux
> import akka.http.scaladsl.server.{Directive1, Route}
> 
> class MyCustomException(msg: String) extends Exception(msg)
> 
> def requireParam[T](name: NameReceptacle[T])
>(implicit pdef: ParamDefAux[NameReceptacle[T], 
> Directive1[T]]): Directive1[T] =
>   parameter(name).recover { _ =>
> throw new MyCustomException(s"${name.name} is missed!")
>   }
>
> It works ok, if I want to create route, using two parameters, for example:
>
> val negSumParams: Route =
>   (requireParam("param1".as[Int]) & requireParam("param2".as[Int])) {
> (param1, param2) =>
>   complete((-param1-param2).toString)
>   }
>
> But if I try to use exactly one parameter, this doesn't compile:
>
> val negParamCompilationFail: Route =
>   requireParam("param".as[Int]) {
> param => // scalac complains about missing type param here
>   complete((-param).toString)
>   }
>
> If I use it with `pass` directive, it works:
>
> val negParamWithPass: Route =
>   (pass & requireParam("param".as[Int])) { // this pass usage looks hacky
> param =>
>   complete((-param).toString)
>   }
>
> If I write `requireParam()` return type explicitly, it works too:
>
> val negParamWithExplicitType: Route =
>   (requireParam("param".as[Int]): Directive1[Int]) { // DRY violation
> param =>
>   complete((-param).toString)
>   }
>
> Why do I need these tricks? Why can't it work just with 
> `requireParam("param".as[Int])`?
>
> Scala version 2.12.1, Akka-HTTP 10.0.10.
>

-- 
>>  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] Connection state in Artery

[Merlijn Boogerd]

I will, thanks for your feedback, much appreciated! :)

Op maandag 13 november 2017 17:10:28 UTC+1 schreef Patrik Nordwall:
>
>
>
> On Mon, Nov 13, 2017 at 4:43 PM, Merlijn Boogerd  > wrote:
>
>> Hi Patrik,
>>
>> Thanks for your fast response! 
>>
>> > In general we recommend against using Akka Remoting without Akka 
>> Cluster, but you might have good reasons for not using Akka Cluster?
>>
>> My reason to not use Cluster is because its complete view of the cluster 
>> members poses a scalability issue beyond a certain size. There's a paper 
>>  where it is 
>> claimed that Akka Cluster scales to 2400 nodes, but my ambition is to scale 
>> quite a bit beyond that. Not sure what your experiences are, but my guess 
>> is that Cluster would not be comfortable with millions of members. My use 
>> case doesn't require everything that Cluster provides either, so I trade 
>> some of its convenience for greater scalability.
>>
>> > I have created issue https://github.com/akka/akka/issues/23967
>>
>> Just for the sake of clarity, if this issue were to be resolved, you 
>> don't see any obvious problems in Artery/Aeron that make it a bad fit for 
>> my use case (using few connections at a time, but many over time)?
>>
>
> The limitation of Aeron is around number of simultaneous streams, as far 
> as I understand. I assume that Aeron will cleanup closed publications 
> (channels), but that is probably something you should test early on
>
> FYI, we are (slowly) working on Artery with TCP 
>  as an alternative to Aeron. 
> That could be a fallback plan if Aeron doesn't fit your needs.
>  
>
>>
>> Kind regards,
>>
>> Merlijn
>>
>>
>>
>> Op zondag 12 november 2017 18:25:16 UTC+1 schreef Patrik Nordwall:
>>>
>>> Hi Merlijn,
>>>
>>>
>>>
>>> On Sun, Nov 12, 2017 at 5:02 PM, Merlijn Boogerd >> > wrote:
>>>
 Hi fellow hakkers,

 I have two questions regarding the Artery module (I am not considering 
 the previous remoting as it will eventually get deprecated). I implemented 
 a peer sampling service (HyParView) and am in the process of implementing 
 a 
 clustering service (Vicinity), both directly on top of Artery. Although it 
 seems to work, I have some worries after delving deeper into Artery and 
 Aeron.

 *Connection control*:
 In my use case, a node may have contacted 1000s of other nodes over 
 time in its lifetime, while only actively using a handful (<10) in a 
 single 
 minute. The services I am implementing are (supposed to be) lightweight, 
 but I see potential reasons why performance might deteriorate over time.

 - Aeron claims 
 
  
 that its number of streams shouldn't be high (never over a thousand, but 
 ideally much lower). It is not clear to me what the costs are for Aeron if 
 a 'connection' is not used (the linked documentation might even refer only 
 to the Publisher/Subscribers directly connected to the MediaDriver, I'm 
 too 
 much of a noob to understand the docs)
 - Artery registers an association for each contacted remote (perhaps 
 more state even, I may have missed stuff). Users don't get to 'close the 
 connection' (I can see reasons why), but Artery does not seem to come with 
 a mechanism to clean unused connections either.

>>>
>>> That is a missing piece that should be fixed. The reason we haven't done 
>>> it yet is partly an oversight and partly because it already works with Akka 
>>> Cluster, since those outbound streams are stopped when a member is removed 
>>> from the cluster (or quarantined for other reasons).
>>>
>>> I have created issue https://github.com/akka/akka/issues/23967
>>>  
>>>

 Can you guys make an educated guess for performance drop in my use 
 case? And if it is significant, what would you advise as a 
 counter-measure? 
 I could see unused-association-garbage collection as a useful addition to 
 Remoting, I would be happy to help out if useful.

 *Quarantining*
 When remote watch fails for some remote actor system, that actor system 
 gets quarantined. In my case, that is a bit radical, as I don't 
 necessarily 
 have control over either of those ActorSystems. Without the ability to 
 reboot either ActorSystem, these systems would continue treating each 
 other 
 as 'down' even though the partition may have long passed. I could 
 instantiate a failure detector explicitly instead of using context.watch, 
 in a way that quarantining is not a consequence of failure-detection. 
 However, it feels like I am missing something with such a simple solution. 
 Why is quarantining as persistent as it is, if skipping it has no 
 downside? 
 What would 

Re: [akka-user] Streaming proxy/tunel on top of akka-http

[johannes . rudolph]

I tried your code and it doesn't OOM for me. Have you tried it outside of a 
test suite? It might be that the test infrastructure is collecting all the 
data when you use something as `reponse.entity`.  If that doesn't 
help,  try capturing a heap dump on OOM and see where the memory is spent.

Johannes

On Wednesday, November 8, 2017 at 11:01:18 AM UTC+1, Jozsef Zsido wrote:
>
> Hi,
>
> Not much code I have, basically I took a sample for akka-http proxy: 
> https://gist.github.com/kovacshuni/afb7d53f40f501d0ab82
>
> trait BrowseServerRoutes3 {
>
>   implicit val system = ActorSystem("Browse")
>   implicit val materializer = ActorMaterializer()
>   implicit val ec = system.dispatcher
>
>   val proxy = Route { context =>
>
> val request = context.request
> println("Processing " + request)
>
> val flow = Http(system).outgoingConnection("10.66.0.4", 80)
>
> Source.single(context.request)
>   .map {
> _.withHeaders(HttpUtils.completeHeaderList(request))
>   .withUri(request.uri.path.toString())
>   }
>   .via(flow)
>   .runWith(Sink.head)
>   .flatMap(f => {
> context.complete(f)
>   })
>   }
> }
>
> object BrowseServer extends App with BrowseServerRoutes3 {
>
>   val binding = Http(system).bindAndHandle(handler = proxy, interface = 
> "0.0.0.0", port = 8080)
>   println(s"Server online.")
> }
>
> "Download" should "return OK" in {
>   Get("/test/huge_MP3WRAP.mp3") ~> proxy ~> check {
> response.status shouldEqual StatusCodes.OK
>   }
> }
>
>
> The first problem I have with this code is that I have a 2GB file at the 
> destination and I get the following exception:
> EntityStreamSizeException: actual entity size (Some(2272610895)) exceeded 
> content length limit (8388608 bytes)! You can configure this by setting 
> `akka.http.[server|client].parsing.max-content-length` or calling 
> `HttpEntity.withSizeLimit` before materializing the dataBytes stream.
>
> I see that the limit could be rised but this seems like akka wants to load 
> the entire data into memory. Actually I don't have a concrete value to put 
> there.
>

-- 
>>  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] Connection state in Artery

[Patrik Nordwall]

On Mon, Nov 13, 2017 at 4:43 PM, Merlijn Boogerd <
merlijn.boog...@trivento.nl> wrote:

> Hi Patrik,
>
> Thanks for your fast response!
>
> > In general we recommend against using Akka Remoting without Akka
> Cluster, but you might have good reasons for not using Akka Cluster?
>
> My reason to not use Cluster is because its complete view of the cluster
> members poses a scalability issue beyond a certain size. There's a paper
>  where it is
> claimed that Akka Cluster scales to 2400 nodes, but my ambition is to scale
> quite a bit beyond that. Not sure what your experiences are, but my guess
> is that Cluster would not be comfortable with millions of members. My use
> case doesn't require everything that Cluster provides either, so I trade
> some of its convenience for greater scalability.
>
> > I have created issue https://github.com/akka/akka/issues/23967
>
> Just for the sake of clarity, if this issue were to be resolved, you don't
> see any obvious problems in Artery/Aeron that make it a bad fit for my use
> case (using few connections at a time, but many over time)?
>

The limitation of Aeron is around number of simultaneous streams, as far as
I understand. I assume that Aeron will cleanup closed publications
(channels), but that is probably something you should test early on

FYI, we are (slowly) working on Artery with TCP
 as an alternative to Aeron. That
could be a fallback plan if Aeron doesn't fit your needs.


>
> Kind regards,
>
> Merlijn
>
>
>
> Op zondag 12 november 2017 18:25:16 UTC+1 schreef Patrik Nordwall:
>>
>> Hi Merlijn,
>>
>>
>>
>> On Sun, Nov 12, 2017 at 5:02 PM, Merlijn Boogerd 
>> wrote:
>>
>>> Hi fellow hakkers,
>>>
>>> I have two questions regarding the Artery module (I am not considering
>>> the previous remoting as it will eventually get deprecated). I implemented
>>> a peer sampling service (HyParView) and am in the process of implementing a
>>> clustering service (Vicinity), both directly on top of Artery. Although it
>>> seems to work, I have some worries after delving deeper into Artery and
>>> Aeron.
>>>
>>> *Connection control*:
>>> In my use case, a node may have contacted 1000s of other nodes over time
>>> in its lifetime, while only actively using a handful (<10) in a single
>>> minute. The services I am implementing are (supposed to be) lightweight,
>>> but I see potential reasons why performance might deteriorate over time.
>>>
>>> - Aeron claims
>>> 
>>> that its number of streams shouldn't be high (never over a thousand, but
>>> ideally much lower). It is not clear to me what the costs are for Aeron if
>>> a 'connection' is not used (the linked documentation might even refer only
>>> to the Publisher/Subscribers directly connected to the MediaDriver, I'm too
>>> much of a noob to understand the docs)
>>> - Artery registers an association for each contacted remote (perhaps
>>> more state even, I may have missed stuff). Users don't get to 'close the
>>> connection' (I can see reasons why), but Artery does not seem to come with
>>> a mechanism to clean unused connections either.
>>>
>>
>> That is a missing piece that should be fixed. The reason we haven't done
>> it yet is partly an oversight and partly because it already works with Akka
>> Cluster, since those outbound streams are stopped when a member is removed
>> from the cluster (or quarantined for other reasons).
>>
>> I have created issue https://github.com/akka/akka/issues/23967
>>
>>
>>>
>>> Can you guys make an educated guess for performance drop in my use case?
>>> And if it is significant, what would you advise as a counter-measure? I
>>> could see unused-association-garbage collection as a useful addition to
>>> Remoting, I would be happy to help out if useful.
>>>
>>> *Quarantining*
>>> When remote watch fails for some remote actor system, that actor system
>>> gets quarantined. In my case, that is a bit radical, as I don't necessarily
>>> have control over either of those ActorSystems. Without the ability to
>>> reboot either ActorSystem, these systems would continue treating each other
>>> as 'down' even though the partition may have long passed. I could
>>> instantiate a failure detector explicitly instead of using context.watch,
>>> in a way that quarantining is not a consequence of failure-detection.
>>> However, it feels like I am missing something with such a simple solution.
>>> Why is quarantining as persistent as it is, if skipping it has no downside?
>>> What would you guys advise for the case where restarting actor-systems is
>>> not an option yet you would like to use failure-detection?
>>>
>>
>> Failure detection is much more robust when using Akka Cluster, since
>> Terminated message for watch is not triggered until the member is removed
>> from the cluster and not as soon as the failure 

Re: [akka-user] Connection state in Artery

[Merlijn Boogerd]

Hi Patrik,

Thanks for your fast response! 

> In general we recommend against using Akka Remoting without Akka Cluster, 
but you might have good reasons for not using Akka Cluster?

My reason to not use Cluster is because its complete view of the cluster 
members poses a scalability issue beyond a certain size. There's a paper 
 where it is 
claimed that Akka Cluster scales to 2400 nodes, but my ambition is to scale 
quite a bit beyond that. Not sure what your experiences are, but my guess 
is that Cluster would not be comfortable with millions of members. My use 
case doesn't require everything that Cluster provides either, so I trade 
some of its convenience for greater scalability.

> I have created issue https://github.com/akka/akka/issues/23967

Just for the sake of clarity, if this issue were to be resolved, you don't 
see any obvious problems in Artery/Aeron that make it a bad fit for my use 
case (using few connections at a time, but many over time)?

Kind regards,

Merlijn



Op zondag 12 november 2017 18:25:16 UTC+1 schreef Patrik Nordwall:
>
> Hi Merlijn,
>
>
>
> On Sun, Nov 12, 2017 at 5:02 PM, Merlijn Boogerd  > wrote:
>
>> Hi fellow hakkers,
>>
>> I have two questions regarding the Artery module (I am not considering 
>> the previous remoting as it will eventually get deprecated). I implemented 
>> a peer sampling service (HyParView) and am in the process of implementing a 
>> clustering service (Vicinity), both directly on top of Artery. Although it 
>> seems to work, I have some worries after delving deeper into Artery and 
>> Aeron.
>>
>> *Connection control*:
>> In my use case, a node may have contacted 1000s of other nodes over time 
>> in its lifetime, while only actively using a handful (<10) in a single 
>> minute. The services I am implementing are (supposed to be) lightweight, 
>> but I see potential reasons why performance might deteriorate over time.
>>
>> - Aeron claims 
>> 
>>  
>> that its number of streams shouldn't be high (never over a thousand, but 
>> ideally much lower). It is not clear to me what the costs are for Aeron if 
>> a 'connection' is not used (the linked documentation might even refer only 
>> to the Publisher/Subscribers directly connected to the MediaDriver, I'm too 
>> much of a noob to understand the docs)
>> - Artery registers an association for each contacted remote (perhaps more 
>> state even, I may have missed stuff). Users don't get to 'close the 
>> connection' (I can see reasons why), but Artery does not seem to come with 
>> a mechanism to clean unused connections either.
>>
>
> That is a missing piece that should be fixed. The reason we haven't done 
> it yet is partly an oversight and partly because it already works with Akka 
> Cluster, since those outbound streams are stopped when a member is removed 
> from the cluster (or quarantined for other reasons).
>
> I have created issue https://github.com/akka/akka/issues/23967
>  
>
>>
>> Can you guys make an educated guess for performance drop in my use case? 
>> And if it is significant, what would you advise as a counter-measure? I 
>> could see unused-association-garbage collection as a useful addition to 
>> Remoting, I would be happy to help out if useful.
>>
>> *Quarantining*
>> When remote watch fails for some remote actor system, that actor system 
>> gets quarantined. In my case, that is a bit radical, as I don't necessarily 
>> have control over either of those ActorSystems. Without the ability to 
>> reboot either ActorSystem, these systems would continue treating each other 
>> as 'down' even though the partition may have long passed. I could 
>> instantiate a failure detector explicitly instead of using context.watch, 
>> in a way that quarantining is not a consequence of failure-detection. 
>> However, it feels like I am missing something with such a simple solution. 
>> Why is quarantining as persistent as it is, if skipping it has no downside? 
>> What would you guys advise for the case where restarting actor-systems is 
>> not an option yet you would like to use failure-detection?
>>
>
> Failure detection is much more robust when using Akka Cluster, since 
> Terminated message for watch is not triggered until the member is removed 
> from the cluster and not as soon as the failure detector indicates that 
> there might be a problem. In general we recommend against using Akka 
> Remoting without Akka Cluster, but you might have good reasons for not 
> using Akka Cluster?
>
> The reason system messages are so important is that when using watch and 
> Terminated has been triggered we don't want the actors (and ActorSystem) to 
> come back to life again, i.e. no zombies.
>
> If these semantics of watch doesn't match what you need then I suggest 
> that you use your own heartbeating and failure detection. 
>
> /Patrik
>
>  
>
>>

Re: [akka-user] Performance of Akka-Http 2.5.4

[johannes . rudolph]

I missed this post before. 

I'd like to add another point. Akka Http hasn't been performance tested on 
a 40 core machine. The high idle CPU percecntage means that either Akka / 
Akka Http is not configured correctly for this amount of cores or that 
there are actual contention issues at these levels of scale. It would be 
definitely interesting to know what the problem is to offer a better 
default experience for running Akka Http on this kind of hardware.

If you are still listening in, Jakub, it would be nice if you could set 
parallelism-max to the number of cores on your machine and/or set 
`parallelism-factor = 1` as Patrik suggested. One reason for bad 
performance could be that the default parallelism-factor of 3 would lead to 
120 threads battling for resources, starving each other off CPU time maybe 
even while keeping some resource. If this alone doesn't increase 
performance, a few stack dumps from the server process during steady state 
would help because that would likely point out places with high contention.

For anyone else listening in here, I also wanted to stress, that you need 
to put any kind of performance numbers into perspective. We cannot test 
everything in every environment and details usually matter in benchmarks. 
High CPU idle times like in this case mean that something currently just 
doesn't work correctly in this setting. For best performance, you need to 
benchmark for yourself on your own hardware and then be prepared to dig 
into issues.

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

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Viktor Klang]

Depends on what you want to achieve. You can always do
Thread.currentThread.getUncaughtExeptionHandler and pass your exception in
manually (if you don't want to throw a Fatal exception or provide your own
`reporter` (to the ExecutionContext).

On Mon, Nov 13, 2017 at 1:30 PM, Christopher Hunt  wrote:

> Ah yes, uncaught. Thanks for the correction.
>
> On 13 Nov 2017, at 21:12, Viktor Klang  wrote:
>
> When you say "unhandled exception" you mean "uncaught exception"?
>
> On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt 
> wrote:
>
>> Hi everyone,
>>
>> I have a situation where I need to call System.exit upon an actor system
>> having terminated. In some runtime situations, a SecurityException will
>> be thrown and I need that to be propagated as an unhandled exception. I can
>> go into the details of why if required, but my question is how to enable
>> this. Here's my existing termination handler which does what I want.
>> However, I'm wondering if there's a better way given that onComplete and
>> friends all swallow exceptions and pass them onto the Dispatcher's reporter:
>>
>>   system.whenTerminated
>> .andThen {
>>   case _ =>
>> new Thread({ () =>
>>   println("Exiting")
>>   System.exit(exitStatus.getOrElse(1))
>> }: Runnable).start()
>> }
>>
>>
>> Cheers,
>> -C
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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.
>>
>
>
>
> --
> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/akka-user/gZkCvLWhyGc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Christopher Hunt]

Ah yes, uncaught. Thanks for the correction. 

> On 13 Nov 2017, at 21:12, Viktor Klang  wrote:
> 
> When you say "unhandled exception" you mean "uncaught exception"?
> 
>> On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt  wrote:
>> Hi everyone,
>> 
>> I have a situation where I need to call System.exit upon an actor system 
>> having terminated. In some runtime situations, a SecurityException will be 
>> thrown and I need that to be propagated as an unhandled exception. I can go 
>> into the details of why if required, but my question is how to enable this. 
>> Here's my existing termination handler which does what I want. However, I'm 
>> wondering if there's a better way given that onComplete and friends all 
>> swallow exceptions and pass them onto the Dispatcher's reporter:
>> 
>>   system.whenTerminated
>> .andThen {
>>   case _ =>
>> new Thread({ () =>
>>   println("Exiting")
>>   System.exit(exitStatus.getOrElse(1))
>> }: Runnable).start()
>> }
>> 
>> 
>> Cheers,
>> -C
>> -- 
>> >> 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.
> 
> 
> 
> -- 
> 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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/gZkCvLWhyGc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Viktor Klang]

When you say "unhandled exception" you mean "uncaught exception"?

On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt  wrote:

> Hi everyone,
>
> I have a situation where I need to call System.exit upon an actor system
> having terminated. In some runtime situations, a SecurityException will
> be thrown and I need that to be propagated as an unhandled exception. I can
> go into the details of why if required, but my question is how to enable
> this. Here's my existing termination handler which does what I want.
> However, I'm wondering if there's a better way given that onComplete and
> friends all swallow exceptions and pass them onto the Dispatcher's reporter:
>
>   system.whenTerminated
> .andThen {
>   case _ =>
> new Thread({ () =>
>   println("Exiting")
>   System.exit(exitStatus.getOrElse(1))
> }: Runnable).start()
> }
>
>
> Cheers,
> -C
>
> --
> >> 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.
>



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