Re: [akka-user] Re: ANNOUNCE: Akka Streams & HTTP 2.0.2 Released!

[Andrew Gaydenko]

On Friday, January 15, 2016 at 9:15:49 AM UTC+3, Patrik Nordwall wrote:
>
> Play is compatible with Akka 2.4 and Akka Streams 1.0. There will soon be 
> a new Play 2.5 milestone that is compatible with Akka Stream 2.0.
>
> If you have found something that Play is not compatible with Akka 2.4 we 
> would be interested in the details.
>

Yes, I have tried and all is OK with Play + Akka 2.4. It was my mistake, 
sorry.

I have dug in the problem (method not found) and have found Akka 2.4 be 
incompatible with... Scala! He-he... It's a joke. Mostly... :) The thing 
is, I use custom script to start applications which uses scala official 
script rather just raw java. It resulted in using jars (with akka-actor 
2.3.10 among them) in lib directory from the official Scala distribution. 
Bang!..

After switching to java script problems have gone.

-- 
>>  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 tcp proxy protocol support

[Carlos Fau]

Hi Julian,

Did you do any improvement on this?

Thanks,

Carlos

On Tuesday, October 6, 2015 at 12:49:42 PM UTC-3, Julian Howarth wrote:
>
> Thanks Johannes,
>
> I'll start having a dig through and see where I get to. No doubt more 
> questions will follow. Certainly happy to contribute it back when it's 
> working.
>
> Julian
>
> On Tuesday, October 6, 2015 at 3:46:40 PM UTC+1, Johannes Rudolph wrote:
>>
>> Hi Julian,
>>
>> see scaladsl/Http.scala for all the glue code between TCP and HTTP. The 
>> hard thing will be getting the metadata from the proxy implementation into 
>> the requests but I guess putting it in a @volatile var after reading it and 
>> mapping each request would make for a simple solution.
>>
>> In case you get this done, I guess your PROXY implementation and its 
>> integration with HTTP would make a nice PR ;)
>>
>> HTH
>> Johannes
>>
>> On Monday, October 5, 2015 at 6:50:03 PM UTC+2, Julian Howarth wrote:
>>>
>>> Are there any plans to add proxy protocol support for akka-http? If not, 
>>> how difficult would it be  to manually configure in support via a 
>>> flow/stage?
>>>
>>>
>>> The reason we needed is specific but possibly not uncommon:
>>>
>>>
>>>  - we currently use akka-http to provide a websocket api which works 
>>> very well
>>>
>>>  - we deploy on AWS 
>>>
>>>  - we use an AWS Elastic load balancer to distribute traffic to our 
>>> websocket instances
>>>
>>>
>>> The above all works without issue, but we now need to identify the IP 
>>> addresses that the websocket connections originate from. 
>>>
>>>
>>> For HTTP(S) connections, AWS ELB adds an X-Forwarded-For header which 
>>> is already supported in akka-http. However, in order to use AWS ELB for 
>>> websocket connections, the ELB needs to be configured to listen using TCP 
>>> rather than HTTP which means there is no X-Forwarded-For header and instead 
>>> the proxy protocol is used.
>>>
>>>
>>> We already have a stateful stage that manages the proxy protocol for our 
>>> TCP connections but what I need some guidance with is how to use that when 
>>> using the HTTP bindings. Any ideas?
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Julian
>>>
>>

-- 
>>  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] Nginx error when proxying to Akka Http and large response sizes

[Chris Baxter]

We just finished our conversion of all of our rest endpoints from 
Unfiltered to Akka Http.  In doing so, we noticed a strange error when we 
have our nginx (version 1.6) proxy sitting in front of Akka Http.  If the 
response is a bit large, over say 30K, nginx fails with the following error:

upstream prematurely closed connection while reading upstream


The only way we could find to fix this was to explicitly chunk responses 
that were larger than a specified size.  I used a piece of code like this 
to handle the chunking.

  def chunkResponses(chunkThreshold:Int) = mapResponseEntity{
case h @ HttpEntity.Strict(ct, data) if data.size > chunkThreshold =>   

  val chunks = 
Source.
  single(data).
  mapConcat(_.grouped(chunkThreshold).toList).
  map(HttpEntity.Chunk.apply(_))
  HttpEntity.Chunked(ct, chunks)
case other => other
  }


All of the responses we had been producing were always HttpEntity.Strict as 
we always had all of the json that we were going to respond with in memory 
already.  I did not see any need to chunk.  I want to better understand why 
this is happening.  Has anyone else run into this?  I couldn't find much 
info out there on this.  The closest thing I found was someone else seeing 
this a while back with their own http server impl:

https://github.com/ztellman/aleph/issues/169

-- 
>>  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] Nginx error when proxying to Akka Http and large response sizes

[Chris Baxter]

We just finished our conversion of all of our rest endpoints from 
Unfiltered to Akka Http.  In doing so, we noticed a strange error when we 
have our nginx (version 1.6) proxy sitting in front of Akka Http.  If the 
response is a bit large, over say 30K, nginx fails with the following error:

upstream prematurely closed connection while reading upstream


The only way we could find to fix this was to explicitly chunk responses 
that were larger than a specified size.  I used a piece of code like this 
to handle the chunking.

  def chunkResponses(chunkThreshold:Int) = mapResponseEntity{

case h @ HttpEntity.Strict(ct, data) if data.size > chunkThreshold =>  
 

  val chunks = 

Source.

  single(data).

  mapConcat(_.grouped(chunkThreshold).toList).

  map(HttpEntity.Chunk.apply(_))

  HttpEntity.Chunked(ct, chunks)

case other => other

  }


All of the responses we had been producing were always HttpEntity.Strict as 
we always had all of the json that we were going to respond with in memory 
already.  I did not see any need to chunk.  I want to better understand why 
this is happening.  Has anyone else run into this?  I couldn't find much 
info out there on this.  The closest thing I found was someone else seeing 
this a while back with their own http server impl:

https://github.com/ztellman/aleph/issues/169


-- 
>>  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 File Not Found Exception

[Konrad Malawski]

Oh wait you should check
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/http/directives/file-and-resource-directives/getFromFile.html

I'm already in bed though ;)
On Jan 16, 2016 00:01, "Konrad Malawski" 
wrote:

> This may be a bug, I'll look into it soon so thanks for reporting!
> Glad you liked the talk :-)
>
> --
> Cheers,
> Konrad 'ktoso’ Malawski
> Akka  @ Typesafe 
>
> On 15 January 2016 at 23:57:01, Gustavo Politano (
> gustavo.polit...@gmail.com) wrote:
>
> Hi!
>
> I was watching Konrad's workshop from Scala eXchange - amazing talk, btw -
> (
> https://skillsmatter.com/skillscasts/6869-workshop-end-to-end-asynchronous-back-pressure-with-akka-streams)
> and latter playing with the code.
>
> On step 3 is demoed a stream completed with a file from disk. I changed
> the name of the file to a inexistent one, so I could force an exception and
> check the exception handling. My expectation was that the browser would
> receive an HTML with the exception details, since the following handler is
> used:
>
>
>  val myExceptionHandler = ExceptionHandler {
>
>   case ex: Exception =>
>
> complete {
>
>   
>
> 
>
>   {ex.getMessage}
>
> 
>
>   
>
> }
>
> }
>
>
>  // our routes:
>
> val route: Route = handleExceptions(myExceptionHandler) {
>
>   helloRoutes ~ simpleStreamRoutes
>
> }
>
>
>  But what happened was that the connection was reset in Safari and it 
> received nothing. When I tested on Chrome, I saw that it started the download 
> of a file with the wrong name, but it failed with a network error as well. On 
> the console I could see the following:
>
>
>
>  [ERROR] [01/15/2016 13:45:06.181] [default-akka.actor.default-dispatcher-12] 
> [akka.actor.ActorSystemImpl(default)] Outgoing response stream error
>
> java.io.FileNotFoundException: .data.csv (No such file or directory)
>
>  at java.io.RandomAccessFile.open(Native Method)
>
> at java.io.RandomAccessFile.(RandomAccessFile.java:243)
>
> at akka.stream.impl.io.FilePublisher.preStart(FilePublisher.scala:49)
>
>   at akka.actor.Actor$class.aroundPreStart(Actor.scala:485)
>
>   at 
> akka.stream.impl.io.FilePublisher.akka$stream$actor$ActorPublisher$$super$aroundPreStart(FilePublisher.scala:34)
>
> at 
> akka.stream.actor.ActorPublisher$class.aroundPreStart(ActorPublisher.scala:322)
>
>  at akka.stream.impl.io.FilePublisher.aroundPreStart(FilePublisher.scala:34)
>
> at akka.actor.ActorCell.create(ActorCell.scala:590)
>
> at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:461)
>
>at akka.actor.ActorCell.systemInvoke(ActorCell.scala:483)
>
>   at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:282)
>
>at akka.dispatch.Mailbox.run(Mailbox.scala:223)
>
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>  at java.lang.Thread.run(Thread.java:745)
>
>
>
>  So my question is if this is the excepted behavior or it's a bug of some 
> sorts. And, if it is the expected behavior, then I don't really understand 
> when the exception handling would kick in, and where I could handle 
> exceptions like this.
>
>
>  Thanks,
>
> Gus.
>
>
>
>
>  PS: link to the original code: 
> https://github.com/ktoso/akka-scala-exchange/blob/master/src/main/scala/samples/scalaexchange/step3/SimpleStreamHttpServiceApp.scala
>
>
>  --
> >> 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] Akka HTTP File Not Found Exception

[Gustavo Politano]

Hi!

I was watching Konrad's workshop from Scala eXchange - amazing talk, btw - 
(https://skillsmatter.com/skillscasts/6869-workshop-end-to-end-asynchronous-back-pressure-with-akka-streams)
 
and latter playing with the code.

On step 3 is demoed a stream completed with a file from disk. I changed the 
name of the file to a inexistent one, so I could force an exception and 
check the exception handling. My expectation was that the browser would 
receive an HTML with the exception details, since the following handler is 
used: 


val myExceptionHandler = ExceptionHandler {

  case ex: Exception =>

complete {

  



  {ex.getMessage}



  

}

}


// our routes:

val route: Route = handleExceptions(myExceptionHandler) {

  helloRoutes ~ simpleStreamRoutes

}


But what happened was that the connection was reset in Safari and it received 
nothing. When I tested on Chrome, I saw that it started the download of a file 
with the wrong name, but it failed with a network error as well. On the console 
I could see the following:



[ERROR] [01/15/2016 13:45:06.181] [default-akka.actor.default-dispatcher-12] 
[akka.actor.ActorSystemImpl(default)] Outgoing response stream error

java.io.FileNotFoundException: .data.csv (No such file or directory)

at java.io.RandomAccessFile.open(Native Method)

at java.io.RandomAccessFile.(RandomAccessFile.java:243)

at akka.stream.impl.io.FilePublisher.preStart(FilePublisher.scala:49)

at akka.actor.Actor$class.aroundPreStart(Actor.scala:485)

at 
akka.stream.impl.io.FilePublisher.akka$stream$actor$ActorPublisher$$super$aroundPreStart(FilePublisher.scala:34)

at 
akka.stream.actor.ActorPublisher$class.aroundPreStart(ActorPublisher.scala:322)

at 
akka.stream.impl.io.FilePublisher.aroundPreStart(FilePublisher.scala:34)

at akka.actor.ActorCell.create(ActorCell.scala:590)

at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:461)

at akka.actor.ActorCell.systemInvoke(ActorCell.scala:483)

at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:282)

at akka.dispatch.Mailbox.run(Mailbox.scala:223)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)



So my question is if this is the excepted behavior or it's a bug of some sorts. 
And, if it is the expected behavior, then I don't really understand when the 
exception handling would kick in, and where I could handle exceptions like this.


Thanks,

Gus.




PS: link to the original code: 
https://github.com/ktoso/akka-scala-exchange/blob/master/src/main/scala/samples/scalaexchange/step3/SimpleStreamHttpServiceApp.scala


-- 
>>  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 File Not Found Exception

[Konrad Malawski]

This may be a bug, I'll look into it soon so thanks for reporting!
Glad you liked the talk :-)

-- 
Cheers,
Konrad 'ktoso’ Malawski
Akka @ Typesafe

On 15 January 2016 at 23:57:01, Gustavo Politano (gustavo.polit...@gmail.com) 
wrote:

Hi!

I was watching Konrad's workshop from Scala eXchange - amazing talk, btw - 
(https://skillsmatter.com/skillscasts/6869-workshop-end-to-end-asynchronous-back-pressure-with-akka-streams)
 and latter playing with the code.

On step 3 is demoed a stream completed with a file from disk. I changed the 
name of the file to a inexistent one, so I could force an exception and check 
the exception handling. My expectation was that the browser would receive an 
HTML with the exception details, since the following handler is used: 



val myExceptionHandler = ExceptionHandler {
  case ex: Exception =>
complete {
  


  {ex.getMessage}


  
}
}


// our routes:
val route: Route = handleExceptions(myExceptionHandler) {
  helloRoutes ~ simpleStreamRoutes
}


But what happened was that the connection was reset in Safari and it received 
nothing. When I tested on Chrome, I saw that it started the download of a file 
with the wrong name, but it failed with a network error as well. On the console 
I could see the following:





[ERROR] [01/15/2016 13:45:06.181] [default-akka.actor.default-dispatcher-12] 
[akka.actor.ActorSystemImpl(default)] Outgoing response stream error
java.io.FileNotFoundException: .data.csv (No such file or directory)
 at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at akka.stream.impl.io.FilePublisher.preStart(FilePublisher.scala:49)
  at akka.actor.Actor$class.aroundPreStart(Actor.scala:485)
  at 
akka.stream.impl.io.FilePublisher.akka$stream$actor$ActorPublisher$$super$aroundPreStart(FilePublisher.scala:34)
at 
akka.stream.actor.ActorPublisher$class.aroundPreStart(ActorPublisher.scala:322)
 at akka.stream.impl.io.FilePublisher.aroundPreStart(FilePublisher.scala:34)
at akka.actor.ActorCell.create(ActorCell.scala:590)
at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:461)
   at akka.actor.ActorCell.systemInvoke(ActorCell.scala:483)
  at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:282)
   at akka.dispatch.Mailbox.run(Mailbox.scala:223)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)




So my question is if this is the excepted behavior or it's a bug of some sorts. 
And, if it is the expected behavior, then I don't really understand when the 
exception handling would kick in, and where I could handle exceptions like this.


Thanks,
Gus.






PS: link to the original code: 
https://github.com/ktoso/akka-scala-exchange/blob/master/src/main/scala/samples/scalaexchange/step3/SimpleStreamHttpServiceApp.scala


--
>> 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] Re: Advice on migration to Akka

[Henrik Johansson]

Thank you, it helps a lot with our confidence to go ahead!

The blocking nature is a definite advantage of going even further but
initially we are a bit hesitant to make too invasive changes.
Small steps!



On Fri, Jan 15, 2016 at 9:21 AM Johan Andrén 
wrote:

> Hi Henrik,
>
> I think this sounds like a good fit for persistance together with sharding.
>
> If you use sharding you will not "know" where the sharded actors are, but
> address them with their id. Your
> controllers will however need to get their hands on the ShardRegion to
> send messages to the sharded actors.
> The shard region will be a local actor and does not move around so it is
> pretty much safe to look it up during
> the bootstrap of your controller and then keep that ActorRef for all your
> interaction.
>
> One reason why it could be an idea to think about moving away from spring
> to akka-http in the future is that
> spring will block one thread until the request is done, so you will have
> to block it to wait for the reply from your
> sharded actor, and keeping that thread from taking other requests. While
> akka-http is asynchronous all the way
> and will allow the "controller" to return the thread pool and then react
> on the reply from the sharded actor.
>
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
>
>
> On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson wrote:
>>
>> Hi,
>>
>> We have finally gotten around to try to migrate a fairly standard Spring
>> REST application to Akka. It will be using the Java API (scala knowledge is
>> moderate at best) and we could need some advice around the approach.
>>
>> The initial thought was to keep using the Spring based REST API i.e. keep
>> all controllers and client facing API/Json serialization and use Akka
>> persistance and sharding for our entities. Why we think this would be good
>> is that we have quite well defined entities where the identity is explicit
>> and guaranteed to be unique. We are also fond of the eventsourcing model.
>> The idea is also that querying the entity for its current state would
>> simple be a matter of rendering its current state and thus saving a trip to
>> the database and result in better performance. We are talking perhaps
>> single digit millions of these entities.
>>
>> Where we find that we lack explicit understanding is how we get hold of
>> the actors from the controllers (or whatever service actually performs
>> actor interactions). Looking up persistent actors (without sharding for
>> simplicity) using Patterns.ask seems to work but we are unclear as to
>> whether or not that is the way to do it. Should we do that whenever we need
>> to get hold of an entity and is there any (significant) overhead? We would
>> prefer not to cache the actors and it seems counterintuitive as well since
>> actors target locations can change. Also maintaining invalidations seems a
>> hassle.
>>
>> Any help and advice would be greatly appreciated. Caveats and gotchas etc
>> also very welcome.
>>
>> Thanks,
>> Henrik
>>
>> --
> >> 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] Re: Advice on migration to Akka

[Johan Andrén]

Hi Henrik,

I think this sounds like a good fit for persistance together with sharding.

If you use sharding you will not "know" where the sharded actors are, but 
address them with their id. Your
controllers will however need to get their hands on the ShardRegion to send 
messages to the sharded actors.
The shard region will be a local actor and does not move around so it is 
pretty much safe to look it up during 
the bootstrap of your controller and then keep that ActorRef for all your 
interaction.

One reason why it could be an idea to think about moving away from spring 
to akka-http in the future is that
spring will block one thread until the request is done, so you will have to 
block it to wait for the reply from your
sharded actor, and keeping that thread from taking other requests. While 
akka-http is asynchronous all the way
and will allow the "controller" to return the thread pool and then react on 
the reply from the sharded actor.

--
Johan Andrén
Typesafe -  Reactive apps on the JVM
Twitter: @apnylle

On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson wrote:
>
> Hi,
>
> We have finally gotten around to try to migrate a fairly standard Spring 
> REST application to Akka. It will be using the Java API (scala knowledge is 
> moderate at best) and we could need some advice around the approach.
>
> The initial thought was to keep using the Spring based REST API i.e. keep 
> all controllers and client facing API/Json serialization and use Akka 
> persistance and sharding for our entities. Why we think this would be good 
> is that we have quite well defined entities where the identity is explicit 
> and guaranteed to be unique. We are also fond of the eventsourcing model. 
> The idea is also that querying the entity for its current state would 
> simple be a matter of rendering its current state and thus saving a trip to 
> the database and result in better performance. We are talking perhaps 
> single digit millions of these entities.
>
> Where we find that we lack explicit understanding is how we get hold of 
> the actors from the controllers (or whatever service actually performs 
> actor interactions). Looking up persistent actors (without sharding for 
> simplicity) using Patterns.ask seems to work but we are unclear as to 
> whether or not that is the way to do it. Should we do that whenever we need 
> to get hold of an entity and is there any (significant) overhead? We would 
> prefer not to cache the actors and it seems counterintuitive as well since 
> actors target locations can change. Also maintaining invalidations seems a 
> hassle.
>
> Any help and advice would be greatly appreciated. Caveats and gotchas etc 
> also very welcome.
>
> Thanks,
> Henrik
>
>

-- 
>>  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: ANNOUNCE: Akka Streams & HTTP 2.0.2 Released!

[Andrew Gaydenko]

On Friday, January 15, 2016 at 9:15:49 AM UTC+3, Patrik Nordwall wrote:
>
> Play is compatible with Akka 2.4 and Akka Streams 1.0. There will soon be 
> a new Play 2.5 milestone that is compatible with Akka Stream 2.0.
>

I mean context when streams (2.x at the momemnt) are used in their own, 
regardless Play.
 

> If you have found something that Play is not compatible with Akka 2.4 we 
> would be interested in the details.
>

OK, I'll report as soon as find an opportunity to try again.

-- 
>>  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: Advice on migration to Akka

[john . vieten]

Hi Johan
just one comment inline...

Am Freitag, 15. Januar 2016 09:21:41 UTC+1 schrieb Johan Andrén:
>
> Hi Henrik,
>
> I think this sounds like a good fit for persistance together with sharding.
>
> If you use sharding you will not "know" where the sharded actors are, but 
> address them with their id. Your
> controllers will however need to get their hands on the ShardRegion to 
> send messages to the sharded actors.
> The shard region will be a local actor and does not move around so it is 
> pretty much safe to look it up during 
> the bootstrap of your controller and then keep that ActorRef for all your 
> interaction.
>
> One reason why it could be an idea to think about moving away from spring 
> to akka-http in the future is that
> spring will block one thread until the request is done, so you will have 
> to block it to wait for the reply from your
>
 
Spring MVC only blocks by default. One can use 
"org.springframework.web.context.request.async.DeferredResult" 
to integrate quite nicely with akka 

sharded actor, and keeping that thread from taking other requests. While 
> akka-http is asynchronous all the way
> and will allow the "controller" to return the thread pool and then react 
> on the reply from the sharded actor.
>
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
>
> On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson wrote:
>>
>> Hi,
>>
>> We have finally gotten around to try to migrate a fairly standard Spring 
>> REST application to Akka. It will be using the Java API (scala knowledge is 
>> moderate at best) and we could need some advice around the approach.
>>
>> The initial thought was to keep using the Spring based REST API i.e. keep 
>> all controllers and client facing API/Json serialization and use Akka 
>> persistance and sharding for our entities. Why we think this would be good 
>> is that we have quite well defined entities where the identity is explicit 
>> and guaranteed to be unique. We are also fond of the eventsourcing model. 
>> The idea is also that querying the entity for its current state would 
>> simple be a matter of rendering its current state and thus saving a trip to 
>> the database and result in better performance. We are talking perhaps 
>> single digit millions of these entities.
>>
>> Where we find that we lack explicit understanding is how we get hold of 
>> the actors from the controllers (or whatever service actually performs 
>> actor interactions). Looking up persistent actors (without sharding for 
>> simplicity) using Patterns.ask seems to work but we are unclear as to 
>> whether or not that is the way to do it. Should we do that whenever we need 
>> to get hold of an entity and is there any (significant) overhead? We would 
>> prefer not to cache the actors and it seems counterintuitive as well since 
>> actors target locations can change. Also maintaining invalidations seems a 
>> hassle.
>>
>> Any help and advice would be greatly appreciated. Caveats and gotchas etc 
>> also very welcome.
>>
>> Thanks,
>> Henrik
>>
>>

-- 
>>  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: Advice on migration to Akka

[Henrik Johansson]

Oh indeed. I knew about this but we have had no need for it.
Seems to be a good idea to revisit it.

Thanks!

On Fri, Jan 15, 2016 at 10:12 AM  wrote:

> Hi Johan
> just one comment inline...
>
>
> Am Freitag, 15. Januar 2016 09:21:41 UTC+1 schrieb Johan Andrén:
>>
>> Hi Henrik,
>>
>> I think this sounds like a good fit for persistance together with
>> sharding.
>>
>> If you use sharding you will not "know" where the sharded actors are, but
>> address them with their id. Your
>> controllers will however need to get their hands on the ShardRegion to
>> send messages to the sharded actors.
>> The shard region will be a local actor and does not move around so it is
>> pretty much safe to look it up during
>> the bootstrap of your controller and then keep that ActorRef for all your
>> interaction.
>>
>> One reason why it could be an idea to think about moving away from spring
>> to akka-http in the future is that
>> spring will block one thread until the request is done, so you will have
>> to block it to wait for the reply from your
>>
>
> Spring MVC only blocks by default. One can use 
> "org.springframework.web.context.request.async.DeferredResult"
> to integrate quite nicely with akka
>
> sharded actor, and keeping that thread from taking other requests. While
>> akka-http is asynchronous all the way
>> and will allow the "controller" to return the thread pool and then react
>> on the reply from the sharded actor.
>>
>> --
>> Johan Andrén
>> Typesafe -  Reactive apps on the JVM
>> Twitter: @apnylle
>>
>> On Thursday, January 14, 2016 at 10:40:44 AM UTC+1, Henrik Johansson
>> wrote:
>>>
>>> Hi,
>>>
>>> We have finally gotten around to try to migrate a fairly standard Spring
>>> REST application to Akka. It will be using the Java API (scala knowledge is
>>> moderate at best) and we could need some advice around the approach.
>>>
>>> The initial thought was to keep using the Spring based REST API i.e.
>>> keep all controllers and client facing API/Json serialization and use Akka
>>> persistance and sharding for our entities. Why we think this would be good
>>> is that we have quite well defined entities where the identity is explicit
>>> and guaranteed to be unique. We are also fond of the eventsourcing model.
>>> The idea is also that querying the entity for its current state would
>>> simple be a matter of rendering its current state and thus saving a trip to
>>> the database and result in better performance. We are talking perhaps
>>> single digit millions of these entities.
>>>
>>> Where we find that we lack explicit understanding is how we get hold of
>>> the actors from the controllers (or whatever service actually performs
>>> actor interactions). Looking up persistent actors (without sharding for
>>> simplicity) using Patterns.ask seems to work but we are unclear as to
>>> whether or not that is the way to do it. Should we do that whenever we need
>>> to get hold of an entity and is there any (significant) overhead? We would
>>> prefer not to cache the actors and it seems counterintuitive as well since
>>> actors target locations can change. Also maintaining invalidations seems a
>>> hassle.
>>>
>>> Any help and advice would be greatly appreciated. Caveats and gotchas
>>> etc also very welcome.
>>>
>>> Thanks,
>>> Henrik
>>>
>>> --
> >> 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.