[akka-user] Akka Http 10.1.0 Released

['Johannes Rudolph' via Akka User List]

Dear hakkers,


we are happy to announce Akka Http 10.1.0, the first release of the 10.1.x 
series.


See the announcement 
at https://akka.io/blog/news/2018/03/08/akka-http-10.1.0-released.


The most important changes are:

   - The new client pool implementation introduced in 10.0.11 is now the 
   default. We have identified and fixed several bugs in the RC period so by 
   now we are quite confident that the new client pool will be a solid 
   replacement for the legacy one.
   - Documentation has been completely consolidated between Scala and Java 
   pages. Hundreds of directive documentation pages have been merged in a 
   tireless effort by @jonas , @jlprat 
   , and Akka team’s @raboof 
   . The overall documentation structure has 
   been improved.
   - Experimental artifacts are available for Scala 2.13.0-M3.
   - Support for Akka 2.4.x, which is at its end-of-life with the end of 
   2017, has been removed. In the future, this will allow us to make use of 
   features that only Akka 2.5 supports.
   - Methods deprecated during the life-time of Akka HTTP 10.0.x have been 
   removed. Methods just deprecated for 10.0.11 have not yet been removed to 
   allow for a smooth transition.

New client pool implementation is now the default


The new client pool implementation introduced in 10.0.11 is now the 
default. Since 10.0.11, we fixed several bugs in the new client pool 
implementation. You can still fall back to the old implementation by 
setting akka.http.host-connection-pool.pool-implementation = legacy.

Akka is not an explicit dependency anymore / Removal of Akka 2.4 support

Akka HTTP 10.0.x has always supported Akka 2.5, while allowing users to 
still remain on Akka 2.4.x if they choose to do so. By now Akka 2.4 has 
reached its end of life. Therefore, Akka HTTP 10.1.x only supports Akka >= 
2.5.11 (and future versions during the life of Akka HTTP 10.1.x) so we will 
be able to make of features only provided by Akka 2.5. In some cases we 
bump the minimum supported patch version of Akka to be able to use new 
features quickly.


Using Akka HTTP with Akka 2.5 used to be a bit confusing, because Akka HTTP 
explicitly depended on Akka 2.4. Trying to use it together with Akka 2.5, 
running an Akka HTTP application could fail with class loading issues if 
you forgot to add a dependency to both akka-actor and akka-stream of the 
same version. For that reason, we changed the policy not to depend on 
akka-stream explicitly anymore but mark it as a provided dependency in our 
build. That means that you will always have to add a manual dependency to 
akka-stream (veterans may remember this policy from Spray).


Please make sure you have chosen and added a dependency to akka-stream when 
updating to the new version.


Currently, the right dependency to add is


libraryDependencies += "com.typesafe.akka" %% "akka-stream" % "2.5.11"


Support for Scala 2.13.0-M3


Akka HTTP 10.1.0 is released for Scala 2.11, 2.12, and 2.13.0-M3. Due to a 
regression 
in Scala 2.13.0-M3  tail 
call optimization does not apply anymore in some cases where it did before 
which might lead to stack overflow when running with Scala 2.13.0-M3.

Deprecation Removals

Methods were removed that have been deprecated during the life-time of Akka 
HTTP 10.0.x. Methods that were only deprecated in the last release of Akka 
HTTP, 10.0.11, are not yet removed to allow for a smooth transition. In 
general, our guarantee for minor release updates is that code that compiled 
on the latest version of the previous minor release (10.0.11 in this case) 
should be both source and binary compatible with the latest version of the 
current minor release. We might make exceptions to the rule for cases where 
the maintenance burden seems greater than the risk of breaking major users 
/ third-party libraries. We’ll treat any other binary incompatibilities as 
regressions.

Compatibility Notes

As the compatibility notes 
 
explain 
in detail, we guarantee binary compatibility. In some cases, however, a new 
version is not strictly source compatible. We try to limit the impact of 
these kinds of changes but sometimes, they are inevitable to improve the 
API.

Source incompatible changes are:

   - Removed deprecated methods from 10.0.x
   - ServerBinding.unbind return type has been changed to Future[Done] / 
   CompletionStage[Done] for consistency.

Removal of OSGi support

Supporting OSGi is error prone and high maintenance and it repeatably 
broke, blocked releases, or metadata turned out to be wrong. As we are no 
experts in OSGi, and are nowadays focusing our efforts on JDK9+ jigsaw 
compatibility we had to remove OSGi support for now. If you care about OSGi 
support please step up and help out. Most important would be adding tests 
that verify 

[akka-user] Akka HTTP 10.1.0-R2 Released

['Johannes Rudolph' via Akka User List]

Dear hakkers,


we are happy to announce Akka Http 10.1.0-RC2, the second release candidate 
for the upcoming Akka HTTP 10.1.0 release. We focused on stabilizing the 
new client connection pool. Over the last month our test suite caught lots 
of edge cases that were fixed for this release. Also, we improved logging 
output for the new pool.


We also merged a lot of small (but valuable!) contributions.


Please try out the new release candidate, especially for client usages, so 
that we gain confidence for releasing the final release.


Note, that OSGI support was removed from the build starting with 10.1.0-RC1 
because the sbt OSGI plugin once again broke the release process. If you 
care for OSGI support of Akka HTTP binaries, please step up 
 to reestablish and maintain 
Akka Http’s OSGI support.


List of changesImprovementsakka-http-core
   
   - Add HTTP status code 421 (#1749 
   )
   - Add HTTP status code 103 (#1803 
   )
   - Add Uri.Path ?/ operator #1793 (#1794 
   )
   - Add UserAgent header parse Java Api (#1807 
   )
   - Optimization: Avoid creation of async callback per request in 
   RequestTimeoutStage (#1848 
   )
   - Add application/grpc+proto content type / media type (#1844 
   )
   - LogByteStringTools now logs errors on debug log (it’s a debug feature 
   after all) (#1780 )
   - Suggest valid max-open-requests values on config error (#1806 
   )
   - Log the timed out request on server (#1813 
   )
   - Be more lenient to allow trailing whitespace after chunk size (#1812 
   )
   - In Http().serverLayer use delayCancellation to make behavior 
   consistent with other server entry points (#1822 
   )
   - Add HttpMessage.withProtocol overload to return Scala type (#1730 
   )

akka-http2-support
   
   - Add Tls-session-info header for http/2 (#1432 
   )

akka-http
   
   - Add Java onSuccess overload to take a strict value (#1821 
   )

Infrastructure
   
   - Lots of small documentation fixes
   - Use sbt-header to manage copyright headers
   - Introduce WithLogCapturing trait for suppressing log output for 
   successful tests which allows more aggressive logging by default (which 
   will be shown only for failures)
   - Fix search on documentation pages to return only one version of each 
   page
   - Disable parallel testing on Jenkins to reduce spurious failures

Bug Fixesakka-http-core
   
   - New client pool: Fix double registration for dispatch (#1726 
   )
   - New client pool: Automatically close connection when slot state -> 
   Unconnected (#1724 )
   - New client pool: Make sure that failed and retryable requests are 
   re-dispatched immediately (#1735 
   )
   - New client pool: Ignore “request entity completed” in state 
   WaitingForResponseDispatch (#1774 
   )
   - New client pool: After slot failures remove slot from response 
   dispatching queue (#1775 )
   - New client pool: Log retried request info (#1781 
   )
   - Parse and render token correctly for HttpChallenge and 
   GenericHttpCredentials (#1353 
   )
   - Fix utf16 surrogate pair decoding in utf8 encoder (#1760 
   )
   - Use 431 status code when header exceeds max length for name or value (
   #1800 )
   - Fix customMediaTypes disabling predefined media type parsing (#1786 
   )
   - TLS should close connection when instructed by stream completion (#380 
   )

Credits

A total of 60 issues were closed since 10.1.0-RC1.


The complete list of closed issues can be found on the 10.1.0-RC2 milestone 
 milestones on 
GitHub.


For this release we had the help of 23 contributors – thank you all very 
much!


commits added removed
   35 507 215 Johannes Rudolph
   13 170  78 Johan Andrén
8  83  32 Arnout Engelen

[akka-user] Re: [Akka-Streams] Want to always receive latest element in Sink

['Johannes Rudolph' via Akka User List]

Hi,

in akka-stream, processing is usually run in a fused fashion, i.e. without 
further configuration one stream will run in a single actor so all 
operations are run sequentially. In such a synchronous scenario, there's 
little room for elements to ever get dropped because the actorRef stage 
basically always needs to wait for the consumer stage to finish before it 
can do its own work. At that point the `foreach` stage already can process 
the next element. Fused processing also means that `Thread.sleep` is bad 
thing to do as it will block stream infrastructure and dispatcher threads 
from doing their work.

Try using `mapAsync()` with `akka.pattern.after` to wait (or actually do 
processing) without blocking infrastructure and it will probably start to 
work.

Johannes


On Thursday, January 25, 2018 at 8:03:11 AM UTC+1, sal...@thoughtworks.com 
wrote:
>
> Hello,
>
> We are having a requirement that if a consumer is slower than producer 
> then discard all the elements that cannot be consumed and whenever the 
> consumer gets ready, feed the latest element from producer.
>
> We tried an approach as follows:
>
> Source.actorRef(0, OverflowStrategy.dropHead)   // actor receives data 
>> at every 10 milliseconds
>
> .runWith {
>>println("data received")
>>Thread.sleep(1000)   // mimic consumer processing data in 
>> every 1 second
>> }
>
>
> We shrank the buffer size to 1 (minimal possible) with following settings
>
> private val actorMaterializerSettings = ActorMaterializerSettings(
>> actorSystem).withInputBuffer(1, 1)
>
>
> With this buffer size, Sink pulls data 1 to consume and data 2 to put in 
> buffer at initialization.
>
> While data 1 is getting processed we are dropping data from producer.
>
> When data 1 gets processed after 1000 milliseconds (1 second) ideally I 
> should receive data 10 (and drop 2 - 9 as consumer is slow) but instead I 
> receive data 2 from the buffer. data 2 in our domain is extremely useless 
> as it is stale.
>
> Is there a way to disable buffer at Sink totally and always pull latest 
> data from Source ?
>
>
>

-- 
>>  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] sbt-revolver 0.9.0 released with sbt 1.0.0 support

['Johannes Rudolph' via Akka User List]

Dear fast application restarters,

we just released sbt-revolver 0.9.0 which is the first version of
sbt-revolver cross-built for sbt 0.13.x and 1.0.x. Thanks go to Olli
Helenius / @liff who contributed the sbt 1.0 compatibility changes
(#62).

We also merged a long-standing PR that allows to customize environment
variables for the run (#63). Thanks, Daniel Moran / @danxmoran for
this contribution.

Happy revolving,

Johannes for the Akka Team

-- 
>>  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 websocket server-push model (server sends messages to client)

['Johannes Rudolph' via Akka User List]

Thanks Julian for sharing the example. Indeed, using the BroadcastHub is 
the recommended way to implement something like this.

On Saturday, April 22, 2017 at 1:09:19 AM UTC+2, Julian Howarth wrote:
>
> I may have misunderstood what you want to achieve, but you don't have to 
> use actors if you'd prefer to just use akka-http / akka-streams. As long as 
> you can provide the data you want to broadcast in the form of an 
> akka-streams Source, it is straightforward to connect that to websocket 
> clients via a broadcast hub: 
> http://doc.akka.io/docs/akka/current/java/stream/stream-dynamic.html#Using_the_BroadcastHub
>
> Something like the following works - in Scala, but Java code will be 
> similar:
>
> import akka.NotUsed
> import akka.actor.ActorSystem
> import akka.http.scaladsl.Http
> import akka.http.scaladsl.model.ws.{Message, TextMessage}
> import akka.http.scaladsl.server.Directives._
> import akka.stream.{ActorMaterializer, ThrottleMode}
> import akka.stream.scaladsl.{BroadcastHub, Flow, Keep, RunnableGraph, Sink, 
> Source}
>
> import scala.collection.immutable.Seq
> import scala.concurrent.duration._
>
> object Tester extends App {
>
>   implicit val system = ActorSystem("Server")
>   implicit val mat = ActorMaterializer()
>
>   // The source to broadcast (just ints for simplicity)
>   private val dataSource = Source(1 to 1000).throttle(1, 1.second, 1, 
> ThrottleMode.Shaping).map(_.toString)
>
>   // Go via BroadcastHub to allow multiple clients to connect
>   val runnableGraph: RunnableGraph[Source[String, NotUsed]] =
> dataSource.toMat(BroadcastHub.sink(bufferSize = 256))(Keep.right)
>
>   val producer: Source[String, NotUsed] = runnableGraph.run()
>
>   // Optional - add sink to avoid backpressuring the original flow when no 
> clients are attached
>   producer.runWith(Sink.ignore)
>
>   private val wsHandler: Flow[Message, Message, NotUsed] = 
> Flow[Message]
>   .mapConcat(_ ⇒ Seq.empty[String]) // Ignore any data sent from the 
> client
>   .merge(producer)  // Stream the data we want to the client
>   .map(l => TextMessage(l.toString))
>
>   val route =
> path("ws") {
>   handleWebSocketMessages(wsHandler)
> }
>
>   val port = 8080
>
>   println("Starting up route")
>   Http().bindAndHandle(route, "0.0.0.0", port)
>   println(s"Started HTTP server on port $port")
>
> }
>
>
> If you run the following and connect to ws://localhost:8080/ws you'll see 
> the Ints being output. If you connect a second client, it will also output 
> the same values as the original starting from where the source was up to at 
> the point of connection. 
>
> HTH,
>
> Julian
>
>
> On Friday, April 21, 2017 at 10:38:11 PM UTC+1, Andrew Schenck wrote:
>>
>> I also found out I can simply do PubRef.tell(msg) and it will send the 
>> message to the client. So this is pretty much what that one post described. 
>> Just wanted to make sure if anyone came across this issue they had all the 
>> information I've found.
>>
>>
>>

-- 
>>  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: Chunked response with akka-http 10.x

['Johannes Rudolph' via Akka User List]

Hi Thibault,

if you have the body of the response already as a Source, 
you can create a response with a chunked entity from it like this:

HttpResponse.create()
  .withEntity(HttpEntities.create(contentType, source))

Johannes

On Thursday, April 20, 2017 at 9:56:47 AM UTC+2, Thibault Meyer wrote:
>
> Hi,
>
> I trying akka-http (version 10.x) by creating a small API who generate 
> UUID on demand. For a bulk UUID creation (ex: */uuid1/5000* to get 5000 
> UUID v1), I would like to return a chunked response to avoir building a 
> list of  item on memory.
>
> From Play 2.5 I usually using final Source source = 
> Source.fromGraph(...) but I don't find how to do this with akka-http and 
> akka-stream.
>
> Do you have any idea how to do 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Status 500 for Play Assets after upgrading to Akka 2.5.0

['Johannes Rudolph' via Akka User List]

Hi Gavin,

the current version of Play is not compatible with Akka 2.5.0. This has 
already been fixed for the upcoming Play 2.6 series. I created a ticket to 
investigate if the compatibility fix should be backported to Play 2.5.x as 
well: https://github.com/playframework/playframework/issues/7251

Johannes

On Wednesday, April 19, 2017 at 12:20:22 PM UTC+2, Gavin Baumanis wrote:
>
> Hi there everyone,
>
> I am after some help please with the following...
>
>
> I have upgraded from Akka 2.4.17 to 2.5.0
> I have copy / pasted the reference configuration from the 2.5.0 
> documentation - completely replacing all 2.4.17 configuration.
> And I have also read the 2.4 to 2.5 migration guide - but my issue doesn't 
> seem to be covered in there.
>
> Also - it seems to be a Play issue... but as I have only updated Akka not 
> Play, here seemed appropriate - so I hope that's OK?
>
> I am using;
> * Scala 2.11.8
> * Akka 2.5.0
> * Akka HTTP 10.0.5
>
> The only change I have made is to upgrade Akka and replace the Akka 
> configuration files.
>
> As a result of the upgrade my app throws a 500 error when attempting to 
> load any fixed / public asset.
>
> An example of what is causing the error is below;
>
>  ")">
>
>
>
> which causes the following stack trace;
>
> 19:59:20.319 [application-akka.actor.default-dispatcher-5] - [error] - 
> application -
>
>
> ! @73lillnl9 - Internal server error, for (GET) [/assets/javascripts/
> jquery/jquery-3.1.1.min.js] ->
>
>
> play.api.http.HttpErrorHandlerExceptions$$anon$1: Execution exception[[
> RuntimeException: java.lang.NoClassDefFoundError: akka/stream/stage/
> StatefulStage]]
>  at play.api.http.HttpErrorHandlerExceptions$.throwableToUsefulException(
> HttpErrorHandler.scala:293)
>  at play.api.http.DefaultHttpErrorHandler.onServerError(HttpErrorHandler.
> scala:220)
>  at play.api.GlobalSettings$class.onError(GlobalSettings.scala:160)
>  at play.api.DefaultGlobal$.onError(GlobalSettings.scala:188)
>  at play.api.http.GlobalSettingsHttpErrorHandler.onServerError(
> HttpErrorHandler.scala:100)
>  at play.core.server.netty.PlayRequestHandler$$anonfun$2$$anonfun$apply$1.
> applyOrElse(PlayRequestHandler.scala:100)
>  at play.core.server.netty.PlayRequestHandler$$anonfun$2$$anonfun$apply$1.
> applyOrElse(PlayRequestHandler.scala:99)
>  at scala.concurrent.Future$$anonfun$recoverWith$1.apply(Future.scala:346)
>  at scala.concurrent.Future$$anonfun$recoverWith$1.apply(Future.scala:345)
>  at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
>  at play.api.libs.iteratee.Execution$trampoline$.execute(Execution.scala:
> 70)
>  at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:
> 40)
>  at scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala
> :248)
>  at scala.concurrent.Promise$class.complete(Promise.scala:55)
>  at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:
> 153)
>  at scala.concurrent.Promise$class.failure(Promise.scala:104)
>  at scala.concurrent.impl.Promise$DefaultPromise.failure(Promise.scala:153
> )
>  at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:257)
>  at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:251)
>  at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32)
>  at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(
> BatchingExecutor.scala:55)
>  at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.
> apply$mcV$sp(BatchingExecutor.scala:91)
>  at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(
> BatchingExecutor.scala:91)
>  at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(
> BatchingExecutor.scala:91)
>  at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72)
>  at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.
> scala:90)
>  at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:38)
>  at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(
> ForkJoinExecutorConfigurator.scala:43)
>  at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>  at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.
> java:1339)
>  at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>  at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.
> java:107)
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: 
> akka/stream/stage/StatefulStage
>  at play.api.mvc.ActionBuilder$$anon$2.apply(Action.scala:463)
>  at play.api.mvc.Action$$anonfun$apply$2$$anonfun$apply$5$$anonfun$apply$6
> .apply(Action.scala:112)
>  at play.api.mvc.Action$$anonfun$apply$2$$anonfun$apply$5$$anonfun$apply$6
> .apply(Action.scala:112)
>  at play.utils.Threads$.withContextClassLoader(Threads.scala:21)
>  at play.api.mvc.Action$$anonfun$apply$2$$anonfun$apply$5.apply(Action.
> scala:111)
>  at play.api.mvc.Action$$anonfun$apply$2$$anonfun$apply$5.apply(Action.
> scala:110)
>  at 

[akka-user] Re: Analogy between reactive streams and electrical currents

['Johannes Rudolph' via Akka User List]

I think that's a valid analogy. A while ago we were investigating similar 
things and also arrived at that analogy. In practice, it turns out that 
fused streams, i.e. multiple stream components that run in one actor will 
skew measurements.

Not sure how much sense these analogies make when going further down this 
route. Just following the types (i.e. the units), we could define the unit 
of resistance as work units per element, which would give us for the 
potential work unit per time. So, the resistance would describe the 
"weight" of the stream element, the potential the speed of the CPU, and the 
intensity the resulting speed of processing.

Johannes

On Friday, April 7, 2017 at 11:42:47 AM UTC+2, Cyrille Corpet wrote:
>
> I have an akka-stream project, in which I'd like to detect bottle-neck 
> stages, to try and optimize them.
>
> I was thinking that it could be useful to use an analogy between streams 
> and electrical currents, to see which parts are more resistive.
>
> Electrical intensity can be easily understood as the rate at which 
> elements are streamed at a given point, in elts/sec. However I have trouble 
> understanding what would be the analog for tension between two points of 
> the flow (or potential at some point) in this setting.
>
> Any ideas? 
> If you think this analogy has no meaning at all, could you explain why, 
> and maybe give me clues on how to find possible bottle-necks ?
>
> Thanks!
>

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

Re: [akka-user] Re: Has akka-http has abandoned per request actors in favor an anti-pattern DSL?

['Johannes Rudolph' via Akka User List]

I think there are a few things that should be treated separately:

 * How to organize bigger route structures?
 * How to implement some parts of the route structure as actors?

As Roland wrote before, a Route is just an alias for a function 
`RequestContext => Future[RouteResult]`. This gives you utmost flexibility 
to structure and implement your routes in every asynchronous way. 
Implementing server behavior in terms of the DLS's `Route` enables you to 
compose your handling logic in a flexible and scalable way while 
centralizing error and failure logic (as rejection and exception handlers).

The routing DSL provides a composable way to specify route logic. For a 
bigger service, it might become a challenge how to organize different 
routes into different files. You can put everything in one file if that's 
what you like but it's not the recommended way. As a Route can be just a 
value we don't force you into a specific kind of dependency injection logic 
or architecture. It's possible to pass context around, use implicits, the 
cake pattern or any other kind of dependency injection library or 
architecture. In this way, Akka HTTP gives you layers to work with but it's 
not a framework that forces you how to structure your application. We know 
that this leaves some challenges to the user and we know that giving more 
guidance in the documentation would be helpful (and we are planning to 
provide more examples and tutorials on those topic in the future).

Using (request) actors to implement parts of the route tree is a technique 
which is orthogonal to the code structure question. Repeating the important 
piece: a Route is just an alias for a function `RequestContext => 
Future[RouteResult]`. That means that you can put in every function which 
implements this type at every point in the route structures. If your route 
processing is stateful and should be implemented in an actor that's 
completely fine. The most general way to implement that in a route is by 
using

def handleByActor(actor: ActorRef): Route = ctx => (actor ? 
ctx).mapTo[RouteResult]

and handle that request in the actor.

However, it might be, that the original point of extracting code into an 
actor isn't as strong a case any more as it was for spray as routes are now 
just returning a Future. If you organize all asynchronous data collection 
into methods returning a Future[XYZ], then you can package all validation 
and processing into directives. After that's done you can express 
everything in a route without the need for any actors.

One point with the route structure seems to be that it requires closing 
over the extracting variables to be concise, if you have this kind of route 
tree

pathPrefix("user" / Segment) { user =>
  session { session =>
parameters('a, 'b, 'c) { (a, b, c) =>
   userRoute(user, session, a, b, c)
}
  }
}

and you want to implement the innermost route somewhere else. Then you have 
to pass all these information explicitly to the inner route. That can be 
cumbersome if the context you have extracted from is big. However, in most 
cases the information is still layered in some ways, so it can make sense 
to package up intermediate information into case class instances or to 
factor out things differently. Another pattern could be to provide the 
outer routes or parts of it as another directive so that it can be reused 
in different parts. We recommend to use routes and directives as they tend 
to be composable and reusable. If you put code into actors it can be harder 
to reuse as actor code often relies on particular messages and asynchronous 
protocols to work correctly.

Johannes


On Sunday, April 9, 2017 at 1:25:36 PM UTC+2, Dominik Dorn wrote:
>
> what a coincidence that I just stumbled upon this thread. I've created a 
> feature request for "actor per request" a few days back in the 
> playframework.
> https://github.com/playframework/playframework/issues/7183
>
> While I was thinking in terms of Play, maybe this is really best suited in 
> the akka-http layer. 
> I also liked the approach lightbend took in "lagom".. there they (it least 
> it looks like they do) transparently convert "service calls" into 
> actors, input datatypes information into a "Request" message and are 
> just waiting for a "Response" message to send back to
> the user, e.g. like in 
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.ServiceCall
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.transport.RequestHeader
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.transport.ResponseHeader
>
> the code posted above
>  case HttpRequest(POST, Uri.Path("/hello"), _, _, _) =>
>   invokeActor(classOf[HelloActor], requestId, request)
> already looks a lot like what I was thinking of. 
>
>
>
>
> On Sun, Apr 9, 2017 at 2:34 AM, Richard Rodseth 

Re: [akka-user] Re: enable hostname / domain name on Akka Http for SSL

['Johannes Rudolph' via Akka User List]

Hi,

that sounds as if you haven't configured Akka HTTP to open an HTTPS server. 
It's hard to say though, as you didn't post any code ;) What code did you 
use to configure Akka HTTP to use HTTPS?

Johannes



On Tuesday, April 18, 2017 at 2:40:08 PM UTC+2, Abdeali Chandanwala wrote:
>
> Hi Arnout,
>
> I am not getting error in my logs nor when I do a postmen/chrome request 
> except this: 
>
> This site can’t be reached
> dev.domainname.in refused to connect.
>
> where-else http protocol works fine with the same deployment
>
> On Tue, Apr 18, 2017 at 5:02 PM, Arnout Engelen <
> arnout.enge...@lightbend.com> wrote:
>
>> Hello,
>>
>> What error do you get when trying to access the https URL? Perhaps 
>> verbose 'curl' logging might be helpful?
>>
>>
>> Kind regards,
>>
>> Arnout
>>
>> On Tue, Apr 18, 2017 at 7:39 AM,  wrote:
>>
>>> Well I am able to deploy the code to the Server and domain name is 
>>> pointing correctly to akka Http - so http://DomainName.COM is working 
>>> fine now ... but same isnt working with https URL i.e 
>>> https://DomainName.COM ..
>>>
>>> I am unable to figure out what am I missing as I have no error reported 
>>> in my logs.
>>>
>>>
>>> On Monday, April 17, 2017 at 5:18:23 PM UTC+5:30, abd...@wealthtech.in 
>>> wrote:

 Hi, 

 I have configured my AKKA Code to import and use SSL in its HTTP via 
 SSLContext The SSL I have used is purchased from GeoTrust (Third 
 Party) 
 and SSL certificate is configured to serve for specific hostname / domain 
 name like "tech.com" - How do I configure Akka to listen for this 
 hostname and not for the IP Address directly - So that the SSL works as 
 needed.

 problem faced: if I send a request using postman on http protocol it 
 works well but https requests fails - as I havent dont any hostname 
 configuration in Akka.

 I am getting some clue on 
 http://doc.akka.io/docs/akka-http/current/java/http/configuration.html but 
 I am confused how do I use this configuration file in my code and 
 following 
 configuration on the above link makes me confuse

  # The proxy configurations to be used for requests with the specified
   # scheme.
   proxy {
 # Proxy settings for unencrypted HTTP requests
 # Set to 'none' to always connect directly, 'default' to use the 
 system
 # settings as described in 
 http://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html
 # or specify the proxy host, port and non proxy hosts as 
 demonstrated
 # in the following example:
 # http {
 #   host = myproxy.com
 #   port = 8080
 #   non-proxy-hosts = ["*.direct-access.net"]
 # }
 http = default

 # Proxy settings for HTTPS requests (currently unsupported)
 https = default
   }


  # If this setting is empty the server only accepts requests that carry a
 # non-empty `Host` header. Otherwise it responds with `400 Bad 
 Request`.
 # Set to a non-empty value to be used in lieu of a missing or empty 
 `Host`
 # header to make the server accept such requests.
 # Note that the server will never accept HTTP/1.1 request without a 
 `Host`
 # header, i.e. this setting only affects HTTP/1.1 requests with an 
 empty
 # `Host` header as well as HTTP/1.0 requests.
 # Examples: `www.spray.io` or `example.com:8080`
 default-host-header = ""


 -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>> Arnout Engelen
>> *Senior Software Engineer*
>> E: arnout.enge...@lightbend.com
>> T: https://twitter.com/raboofje
>>
>>
>> -- 
>> >> 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/yPfP7c6Zloo/unsubscribe.
>> To unsubscribe from this group and all its topics, send 

[akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?

['Johannes Rudolph' via Akka User List]

Hi Alan,

On Friday, March 17, 2017 at 12:25:09 PM UTC+1, Alan Burlison wrote:
>
> pathPrefix("root") { 
>concat( 
>   pathPrefix("service1") { service1.route }, 
>   pathPrefix("service2") { service2.route } 
>) 
> } 
>
 

> That works fine with a path of say "/root/service1", but it 
> *also* matches "/rootnotroot/service1", because pathPrefix() just 
> matches any arbitrary string prefix and not a full path segment.
>


 No, it doesn't match `/rootnotroot/service1` (or it least it should not). 
You are right, that `pathPrefix(string)` only matches a prefix of the 
string, but it also matches a leading slash. So, if you are using the 
recommended `pathPrefix("xyz") { pathPrefix("abc") { path("innerMost") } }` 
pattern, then the problem you describe is never a problem as the only path 
that is matched is `/xyz/abc/innerMost`.

The only place where it would matter is if you complete a route from a 
place where not the whole path is expected to be matched, i.e. there's 
still something left in `ctx.unmatchedPath`. Is that what you are doing?

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.

[akka-user] Re: AKKA HTTP: Is this a valid use of Route.seal?

['Johannes Rudolph' via Akka User List]

Hi Alan,

yes, that's a valid use case. The route tree is usually traversed 
completely until a Route matches. But if you know that the search can be 
cut short, then `seal` is definitely a good solution. Another solution 
would be to use only `handleRejections` which would have the advantage that 
only rejections are handled and exceptions will still bubble up and run 
through the exception handlers you have defined further up in your route.

Johannes


On Tuesday, March 7, 2017 at 11:32:37 PM UTC+1, Alan Burlison wrote:
>
> I have an Akka HTTP route for a REST API that first checks the base path, 
> then  checks the user authentication is valid, adds some custom headers and 
> extracts the base URI before processing the sub-routes. However if the URL 
> doesn't match any of the sub-routes, request processing "rolls back" to the 
> authentication step and I get an incorrect message about authentication 
> failing.
> ​ ​
> ​I've wrapped the sub-route processing in Route.seal and that ​​means that 
> I​ now get a "Not Found" 
> ​for nonexistent paths, ​
> as required
> ​. However the documentation says that Route.seal ​
> ​shouldn't really be needed for application code. Is this a valid use of 
> Route.seal, or is there a better way to prevent route processing from 
> "rolling back" past a specified point?​
>
>
> def route: Route = {
>   pathPrefix("rest" / "v1") {
> // If the request authenticates successfully, add the custom headers 
> to the response
> // and extract the base URI we were called with.
> (combinedAuth & respondWithHeaders(versionHeaders) & baseUri ) { 
> (sess, baseUri) => {
>  // Process valid sub-routes, seal the route so we don't roll back 
> past this point.
>   Route.seal(concat(
> pathEndOrSingleSlash { topRoute(sess, baseUri) },
> pathPrefix("users")  { userRoute(sess, baseUri) }
>   ))}
> }
>   }
> }
>
> -- 
> Alan Burlison
> --
>

-- 
>>  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 client future+flatMap or flow+asyncMap?

['Johannes Rudolph' via Akka User List]

Hi Brice,

we previously recommended the stream variant 
(`Source.single(request).mapAsync(1))`) but it turned out that this is not 
a good idea as materialization has some cost and the API is more complex 
than using `Http.singleRequest()` directly. So, using 
`Http.singleRequest()` is the right way to go.

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.

[akka-user] Re: illegal-rawheaders

['Johannes Rudolph' via Akka User List]

Hi Dimitry,

that message is a different one. It means that your code is issuing 
requests with an explicit header `RawHeader("User-Agent", ...)` somewhere.

Johannes

On Thursday, February 23, 2017 at 8:10:03 PM UTC+1, 
dmitriy...@alisagaming.com wrote:
>
> Hi everyone.
>
> I've been using akka with spray and, later, akka-http.
>
> Right now I'm confused with configuration and *illegalHeaderWarnings* in 
> particular.
>
> First, I added this to my *application.conf*:
>
>
> akka.http {
>
>  host-connection-pool {
>  parsing.illegal-header-warnings = off
>  parsing.error-logging-verbosity = off
>  }
>
>  parsing.illegal-header-warnings = off
>
>  server {
>  idle-timeout=600s
>  request-timeout=600s
>  remote-address-header=true
>  }
>
> }
>
>
>
> With no result. I've overridden the values programmatically:
>
> private val settings = ConnectionPoolSettings(config = 
> Application.system.settings.config)
> private val cs = settings.connectionSettings
> private val ps = settings.connectionSettings.parserSettings
> private val _settings = 
> settings.withConnectionSettings(cs.withParserSettings(ps.withIllegalHeaderWarnings(false)))
> lazy val pool = Http().cachedHostConnectionPoolHttps[Int](
>  host = ""
>  , port = 443
>  , settings = _settings
>  , connectionContext = SSLSupport.sslContext
> )
>
> Same here. I keep receiving thousands of beautiful messages like this:
>
>
> [WARN] [02/23/2017 18:51:24.596] [default-akka.actor.default-dispatcher-9] 
> [akka.actor.ActorSystemImpl(default)] Explicitly set HTTP header 'User-Agent: 
> akka-http/10.0.3' is ignored, illegal RawHeader
>
> What can I do now?
>
> It seems that the related bugs were closed in 2015.
>
> --
> WBR
> Dmitry
>

-- 
>>  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: Detail: akka.stream.StreamTcpException: Connection failed.

['Johannes Rudolph' via Akka User List]

Hello,

the error is thrown 
here: 
https://github.com/akka/akka/blob/master/akka-stream/src/main/scala/akka/stream/impl/io/TcpStages.scala#L303.
 
I agree it's hard to see why that error would happen. One thing that could 
have happened is that a connection attempt was very slow and so the 
idle-timeout kicked in and killed the TCP stage before a connection was 
established. Either there was a real connection problem, or the 
infrastructure didn't make progress in due time e.g. because of a thread 
starvation issue.

Btw. using `Source.single().via(connectionFlow).runWith(Sink.head)` is 
discouraged. Please use `Http.singleRequest` instead. See also the note 
at 
http://doc.akka.io/docs/akka-http/current/scala/http/client-side/host-level.html#host-level-api.

HTH
Johannes



On Monday, February 27, 2017 at 8:25:37 AM UTC+1, Chaitanya Mahipath wrote:
>
> Hi,
>
> I am using the akka http scaladsl library to do a HTTP calls against a 
> server. I am running a test where I have 15 threads running concurrently 
> each making around 250 GET calls(15*250). Trying to run this test for three 
> hours but I see that after two and half hours of execution I could see
> Detail: akka.stream.StreamTcpException: Connection failed. exception being 
> thrown.
>
> Initially I thought the servers isn't accepting the incoming requests. 
> But, ran the same test directly against the server and could see no issues.
> Code snippet to connect to the server -
>
> connectionFlow= 
> Http(context.system).outgoingConnectionTls(req.uri.authority.host.address(), 
> port)
> Source.single(req.withUri(req.uri.toRelative)).via(connectionFlow).runWith(Sink.head)
>  
> - Here, req is the HttpRequest.
>
> Could someone please help me out why is that StreamTcpException exception 
> is thrown?
>

-- 
>>  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: XMPP chat server vs Akka TCP

['Johannes Rudolph' via Akka User List]

Hi,

XMPP is an application-level protocol while TCP is a transport-level 
protocol. In fact, XMPP usually runs *on top of* TCP. So, yes, you can use 
Akka TCP to implement XMPP.

Comparing XMPP to what you probably have right now is that in your current 
application you used your own custom protocol the clients use to talk to 
your chat server. On the other side, XMPP is a standard for a chat protocol 
that defines how messages should be sent over the wire.

Fwiw it seems that XMPP in fact supports different kinds of transport 
protocols: 
https://en.wikipedia.org/wiki/XMPP#XMPP_via_HTTP_and_WebSocket_transports

Cheers,
Johannes

On Thursday, February 23, 2017 at 3:59:20 PM UTC+1, livetouch wrote:
>
> Hi,
>
> I have to develop a chat web application + android/ios clients.
>
> I did a sample using Akka Actors, using Akka TCP. So I have an 
> TCPUserActor that receives the connection, and after that I have some 
> UserActor for each user in the application.
>
> But I friend told me that chat applications uses XMPP protocol, and that 
> some chats like Gmail, Messanger, Whatsapp uses it..
>
> So the question is, can I use just Akka TCP for my chat application? Or 
> XMPP is better for this?
>
> Or can I use Akka TCP + XMPP together?
>
> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Stream file to disk without holding memory

['Johannes Rudolph' via Akka User List]

Hi David,

the 503 is generated by the timeout logic, see the 
`akka.http.server.request-timeout` setting. See the timeout directives for 
ways to change it based on the 
request: 
http://doc.akka.io/docs/akka-http/10.0.3/scala/http/routing-dsl/directives/timeout-directives/index.html

Regarding the memory problem. Could you also check if the output of `jmap 
-histo:live ` agrees with more and more memory being held? What does 
the output look like?

Johannes

On Friday, February 3, 2017 at 5:33:08 PM UTC+1, David Puleri wrote:
>
> I am trying to stream large files to an endpoint. To briefly describe what 
> this code does : - It generates a valid path, then stream the data to the 
> disk, then store metadata.
>
> It works well expect for one thing : The file seems to be stored in memory 
> (as well as on the disk). My memory-free collectd metrics keeps going 
> down...
>
> Also, it is worth mentioning that the server returns a 503 error even 
> though the asynchronous process complete just fine. I could add an onError 
> handler but it seems that the future completes OK.
>
>
> Do I need to cleanup something ? Is there something I am missing / doing 
> wrong ?  Any Idea ?
>
>
>
> I curl it like that :
>
> curl --form "videos=@81770ea1-6cde-4a61-a63c-d060970e0084.mkv" 
> http://myserver/videos
>
>
> Thanks for the help! :)  
>
>
>
> fileUpload("videos") {
> case (metadata, byteSource) =>
>   val cdnPath = 
> s"${DateTime.now.year}/${DateTime.now.month}/${DateTime.now.day}"
>   val mountPoint = resolveBestMountPoint()
>   val baseDirectory = s"$mountPoint/$cdnPath/"
>   new JavaFile(baseDirectory).mkdirs()
>   val baseFilename: String = 
> s"${UUID.randomUUID().toString}.${metadata.fileName.split("\\.").last}"
>   val file: Path = Paths.get(mountPoint) resolve 
> s"$cdnPath/$baseFilename"
>   val futureCopyToDisk: Future[IOResult] = 
> byteSource.runWith(FileIO.toPath(file))
>   val storeData: Future[(IOResult, Boolean)] = for {
> isCopied <- futureCopyToDisk
> isPersisted <- {
>   val metaDataOverview = 
> PersistMetadataOverview(s"/$cdnPath/$baseFilename", baseFilename, 
> metadata.contentType, metadata.fileName, isCopied.count, mountPoint)
>   metadataManager.persistMetadata(metaDataOverview)
> }
>   } yield (isCopied, isPersisted)
>   onSuccess(storeData) { (sum, isPersisted) =>
> (sum.wasSuccessful, isPersisted) match {
>   case (true, true) =>
> logInfo(s"File successfully stored and persisted to 
> ${file.toString}")
> complete(HttpResponse(StatusCodes.Created, headers = 
> List(headerLocation(s"/videos/$baseFilename"
>   case (true, false) =>
> 
> reject(UnableToPersistMetaDataToDataStore(file.toString))
>   case (false, true) =>
> reject(UnableToPersistFileToDisk(file.toString))
>   case (false, false) =>
> 
> reject(UnableToPersistFileAndMetadataToDataStore(file.toString))
> }
>   }
>
>   }
>
>

-- 
>>  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] java.lang.VerifyError after shading with sbt-assembly

['Johannes Rudolph' via Akka User List]

Yes, this seems to be a bug in sbt-assembly which gets triggered if you use 
shading. See https://github.com/sbt/sbt-assembly/issues/205
>
>

-- 
>>  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: Memory Leak : akka.actor.RepointableActorRef

['Johannes Rudolph' via Akka User List]

Hi Eric,

we'd like to look into that. It looks as if a streams materializer is 
holding on to some memory but we need more info to see what it keeps 
exactly to.

Is this a reproducible scenario? Could you share the memory dump (in 
private) with us? Otherwise, could you send the list of top consumers (by 
numbers and / or bytes) as seen in MAT?

Thanks,
Johannes

On Friday, February 3, 2017 at 2:56:04 PM UTC-7, Eric Swenson wrote:
>
> I have an akka-http/akka-streams application that I’ve recently upgraded 
> to 10.0.3.  After handling many requests, it runs out of memory.  Using the 
> Eclipse MAT, I see this message:
>
> One instance of *"akka.actor.RepointableActorRef"* loaded by 
> *"sun.misc.Launcher$AppClassLoader 
> @ 0x8b58"* occupies *1,815,795,896 (98.53%)* bytes. The memory is 
> accumulated in one instance of 
> *"scala.collection.immutable.RedBlackTree$BlackTree"* loaded by 
> *"sun.misc.Launcher$AppClassLoader 
> @ 0x8b58"*.
>
> *Keywords*
> akka.actor.RepointableActorRef
> scala.collection.immutable.RedBlackTree$BlackTree
> sun.misc.Launcher$AppClassLoader @ 0x8b58
>
> Does this ring any bells?  How might I track down what is causing this?  
>
> I *believe* that I’ve stressed this service before (in a similar way) and 
> NOT seen this failure. I think I was running 10.0.1 and upgraded to 10.0.2 
> and then 10.0.3 before running the test again.
>
> I don’t really know much about MAT (first time user), but I believe what 
> the “Shortest Paths To The Accumulation Point” report is telling me that 
> akka.stream.impl.ActorMaterializerImpl is what is creating the 
> RepointableActorRef.  I am using akka-streams and I am passing blocks of 
> data of 1MB size through the streams.  But as far as I know, I shouldn’t be 
> accumulating them.  Also, I have successfully run a test of this magnitude 
> before without running out of memory.  
>
> Any suggestions?
>
> — Eric
>
>
>
>

-- 
>>  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] How to call a Future-based test from a Route?

['Johannes Rudolph' via Akka User List]

On Monday, January 2, 2017 at 1:42:27 PM UTC+1, Alan Burlison wrote:
>
> One question: 
>
> headerValueByName("X-Auth-Key")).flatMap { (user, pass) => 
>   // <- user flatMap for custom directives 
>
> doesn't compile as the resulting value of type Directive[(String, 
> String)] doesn't have a flatMap. Do you mean tFlatMap? 
>
>
Yes, right, I forgot that `flatMap` is only defined for Directive1. So, it 
needs to be

headerValueByName("X-Auth-Key").tflatMap { case (user, pass) => 

instead.

-- 
>>  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] How to call a Future-based test from a Route?

['Johannes Rudolph' via Akka User List]

Hi Alan,

here are a few steps to get there:

 * provide all your different authentication directives as values of type 
`Directive1[T]` with T being the type of the principal found after 
successful authentication.
 * To build those, use either one of the existing authentication directives 
starting with `async` or built a directive on your own building on the 
future directives like `onComplete`.
 * In the end combine directives with the `|` operator.
 * In the best case all of the directive would return the same rejection if 
authentication fails. If that's not the case you can either map each of the 
rejections or add a rejection handler around the combination.

For example:

def basicAuth: Directive1[User] = authenticateBasic(null, authenticate) 
def authenticateUserPass(user: String, pass: String): Future[User] = ...
def xAuth: Directive1[User] = 
  (headerValueByName("X-Auth-User") & 
headerValueByName("X-Auth-Key")).flatMap { (user, pass) => // <- user 
flatMap for custom directives
onComplete(authenticateUserPass).flatMap { 
  case Success(user) => provide(user)
  case Failure(ex) => reject(/* with whatever you want */)
}
  }
def sessionAuth: Directive1[User] = // probably similar to xAuth

def combinedAuth = basicAuth | xAuth | sessionAuth

// and then use it

combinedAuth { user =>
  // ...
}

HTH, 
Johannes


On Saturday, December 31, 2016 at 2:17:36 PM UTC+1, Alan Burlison wrote:
>
> > Have you seen the complete list of directives? 
> > There's many directives with "Async" that means that they work on 
> Futures. 
>
> I've seen the async authorization directives but none of them fit the 
> header mechanism I'm trying to emulate. 
> authenticateOrRejectWithChallenge() seems to come closest but on 
> failure I don't want a challenge response, just a rejection. 
>
> I see onComplete() takes a future which looks closer to what I want 
> but how you'd combine an authenticateBasicAsync with two other 
> Future-based custom authentication mechanisms so that you get a single 
> result or a rejection is completely unclear to me. 
>
> I must say that I'm finding the high level Akka-HTTP API rather 
> difficult to use, for simple cases it all looks so easy but as soon as 
> you step outside of that it immediately gets incredibly complicated 
> :-/ 
>
> -- 
> Alan Burlison 
> -- 
>

-- 
>>  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: Latency in using Akka HTTP Client

['Johannes Rudolph' via Akka User List]

Hi Gaurav,

two small remarks:

 * Try using `Http().singleRequest` instead of 
`Souce.single().via(poolClientFlow).run`. Materialization (= `run` / 
`runWith`) has a certain cost that can be avoided using 
`Http().singleRequest`.
 * Using `(1 to 1000).par.foreach` to run the benchmark may lead to strange 
results. Can you say how many requests you are running parallel? How much 
threads do you have? You might be ending up issuing all requests before 
getting a single response, which means with 120 connections that on the 
server request processing has to spread 120 concurrent requests on your 
much smaller number of cores. E.g. with 4 threads, this might mean an extra 
factor of 120/4 = 30 in the latency times. If you are only interested in 
latency, try running single requests, or at least not more than your server 
can process in parallel.

Johannes

On Sunday, January 1, 2017 at 10:54:16 PM UTC+1, Gaurav Kumar wrote:
>
> Hi hAkkers,
>
> I'm using Akka HTTP Client to send a simple request to a local server and 
> I am observing high latencies. The URL is a simple one with no processing 
> and the server is local, machine is high end too.
> Latency observed is ~8-10ms. Instead, it should be ~0-1ms. When using 
> other libraries/methods I get the response in 1ms. Below is the code:
>
> object Main extends Logging {
>   def main(args: Array[String]): Unit = {
> implicit val system = ActorSystem()
> implicit val materializer = ActorMaterializer()
>
> val poolClientFlow = Http().cachedHostConnectionPool[Int]("localhost")
>
> logger.info("warming up...")
> (1 to 1000).par.foreach(id => send(id, poolClientFlow))
>
> Thread.sleep(3000)
>
> logger.info("starting...")
> (1 to 1000).par.foreach(id => send(id, poolClientFlow))
> logger.info("done...")
>
> system.terminate()
>   }
>
>   val uri = "/"
>
>   private def send(id: Int, poolClientFlow: Flow[(HttpRequest, Int), 
> (Try[HttpResponse], Int), HostConnectionPool])(implicit system: ActorSystem, 
> materializer: ActorMaterializer): Unit = {
> import system.dispatcher
> val source: Source[(Try[HttpResponse], Int), NotUsed] = 
> Source.single(HttpRequest(uri = uri) -> id).via(poolClientFlow)
> val start: Long = System.nanoTime()
> val future: Future[(Int, String)] = source.runWith(Sink.head).flatMap {
>   case (Success(response), id: Int) =>
> Unmarshal(response.entity).to[String].map(result => (id, result))
>   case _ =>
> throw new Exception("FAILED")
> }
> val result: (Int, String) = Await.result(future, 10 seconds)
> logger.info(s"TIME: ${(System.nanoTime() - start) / 100} ID: 
> ${result._1}")
>   }
> }
>
>
>
> application.conf is:
>
> akka {
>   loglevel = DEBUG
> }
>
> akka.http {
>   host-connection-pool {
> max-connections = 120
> min-connections = 1
> max-retries = 0
> max-open-requests = 4096
> pipelining-limit = 1
> idle-timeout = 30 s
> client = {
>   connecting-timeout = 10s
>   idle-timeout = 60 s
> }
>   }
> }
>
>
>
> It's a simple hello world code but I am not sure the reason for low 
> performance.
>
> Thanks,
> GK
>

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

['Johannes Rudolph' via Akka User List]

Dear hakkers,


We are proud to announce Akka Http 10.0.1, which is the first
maintenance release of the Akka Http 10.0 series, and also our small
holiday present to you.

Some notable improvements and bug fixes are:

Lots of documentation improvements thanks to our awesome contributors.
Improved (debug) log messages for the infamous "No elements passed in
the last 1 minute." timeout exception andOutputTruncationException.
Both exceptions will now include more information about the context
and the actual reason for the failure in the context of HTTP. More
improvements will be made here in the future.

We still have lots of exciting pull requests open that didn't make the
cut this time. In the coming month we will continue to merge your
contributions and will also continue the work on HTTP/2.

Credits

A total 17 issues were closed since 10.0.1. The complete list of
closed issues can be found on the 10.0.1 milestones on github.

For this release we had the help of 21 committers – thank you all very much!

Credits:
commits  added  removed
 14429  310 Johannes Rudolph
  7207   16 Konrad `ktoso` Malawski
  6238  109 Josep Prat
  3 52   24 Jonas Fonseca
  2 68   48 Konrad Malawski
  1751   34 Richard S. Imaoka
  1107   16 Jędrzej Nowowiejski
  1 16   18 Jeffrey Warren
  1 16   16 Richard Imaoka
  1 290 Jens
  1 230 Schmitt Christian
  1 135 Martynas Mickevičius
  1  98 Assil Ksiksi
  1  2   12 Michal Sitko
  1 120 sidfeiner
  1  30 Eric Swenson
  1  03 Witi
  1  11 Seth Tisue
  1  11 Nathan Waldman
  1  11 EnverOsmanov
  1  11 Sergiusz Kierat

Happy hakking!

– The Akka Team

-- 
>>  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] String cannot be cast to Message

['Johannes Rudolph' via Akka User List]

Hi Ronny,

I agree that error message is little helpful. Maybe you are sending plain 
Strings to the actor created by Source.actorRef? (Still we might want to 
improve the error message in that case.)

Johannes

On Monday, September 19, 2016 at 12:08:52 AM UTC+2, Ronny Bräunlich wrote:
>
> Hi everyone,
>
> I am quite new to Akka and Websockets. I tried to create a simple 
> Websocket server using Akka HTTP following mostly this example [1].
> Everytime I send a message to my own server I get the following exception:
>
> [ERROR] [09/18/2016 15:37:01.533] 
> [default-akka.actor.default-dispatcher-4] 
> [akka.actor.ActorSystemImpl(default)] WebSocket handler failed with 
> java.lang.String cannot be cast to akka.http.javadsl.model.ws.Message
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> akka.http.javadsl.model.ws.Message
> at akka.stream.impl.fusing.Map$$anon$8.onPush(Ops.scala:42)
> at 
> akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:747)
> at 
> akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:710)
> at 
> akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:616)
> at 
> akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:471)
> at 
> akka.stream.impl.fusing.GraphInterpreterShell.receive(ActorGraphInterpreter.scala:410)
> at 
> akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:603)
> at 
> akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:618)
> at akka.actor.Actor.aroundReceive(Actor.scala:484)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
> at akka.actor.ActorCell.invoke(ActorCell.scala:495)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
> at akka.dispatch.Mailbox.run(Mailbox.scala:224)
> at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> at 
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> at 
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
>
> Currently, I have no idea why it crashes like this because the method 
> handleWebSocketMessages() expects a Flow so there is 
> no chance I could use a String. Did I miss some configuration for implicit 
> conversion?
>
> You can see the server here [2] and the client here [3]. I am using Akka 
> HTTP Core and Experimental 2.12.0-RC1 version 2.4.10.
>
>
> Thank you for your help.
>
> Cheers,
> Ronny
>
> [1] 
> http://markatta.com/codemonkey/blog/2016/04/18/chat-with-akka-http-websockets/
> [2] https://gist.github.com/rbraeunlich/e2582075e2ccc0fd63580bdd95585aa5
> [3] https://gist.github.com/rbraeunlich/eded91382d72a3d90e8182ca1b077d01
>

-- 
>>  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: Trigger some logic at the moment of TCP connection established

['Johannes Rudolph' via Akka User List]

Hi Yaroslav,

you may want to create a custom GraphStage in that case that waits for the 
first data to arrive and then prepend the extra-data. Afterwards you can 
change the state of the GraphStage to forward messages 1-to-1.

Johannes

On Tuesday, September 20, 2016 at 4:00:23 PM UTC+2, Yaroslav Klymko wrote:
>
> Basically I'd like to prepend something, but at the moment first 
> ByteString received, I mean that prepended value should not be in the 
> stream in case of connection failure.
>
> On Tuesday, September 20, 2016 at 1:44:56 PM UTC+3, Johannes Rudolph wrote:
>>
>> Hi Yaroslav,
>>
>> no worries, this is a good question. It depends a bit on what kind of 
>> logic you want to trigger. If you just want to do something, you can use 
>> `mapMaterializedValue` to do something with the `OutgoingConnection` object 
>> before materialization is complete.
>>
>> If you want to prepend some bytes to be output to the connection, you can 
>> do it like this:
>>
>> Flow[ByteString]
>>   .prepend(Source.single(ByteString("hello connection"))) // or any other 
>> source
>>   .via(Tcp(system).outgoingConnection(???, ???))
>>
>> More complex behavior can be built e.g. by wrapping the complete 
>> connection flow with a custom GraphStage that would be able to receive all 
>> kinds of signals.
>>
>> HTH
>> Johannes
>>
>>
>>
>> On Thursday, September 15, 2016 at 12:32:02 PM UTC+2, Yaroslav Klymko 
>> wrote:
>>>
>>> Either my question is silly or there is no easy answer.
>>>
>>> On Saturday, September 10, 2016 at 3:57:33 PM UTC+3, Yaroslav Klymko 
>>> wrote:

 Hi guys,

 I'm trying to figure out on how to trigger some logic at the moment TCP 
 connection established, and preferably *before traffic goes*
 Initial code looks like this:


 Tcp(system).outgoingConnection(???, ???).join(flow).runWith(source, sink)



 As far as I can see I need to access Future[OutgoingConnection]


 val outgoingConnection: Flow[ByteString, ByteString, 
 Future[OutgoingConnection]] = Tcp(system).outgoingConnection(???, ???)



 So far I came to:


 val (_, connected: Future[Tcp.OutgoingConnection], _) = 
 Source.fromGraph(source).viaMat(connection)(Keep.both).toMat(sink)(Keep.both).run()



 Question 1: how to guarantee my code performed before first ByteString 
 came?
 Question 2: is there better solution
 Question 3: how to prepend connection as first event in the flow of 
 ByteStrings ?



-- 
>>  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-Streams] Creating a custom async filter

['Johannes Rudolph' via Akka User List]

Hi Simon,

you could also try to split up the asynchronous computation and the actual 
filtering like this:

def filterFunc(e: E): Future[Result]

xyz.mapAsync(n)(e => filterFunc(e).map(res => e -> res))
   .via(statefulFilterGraphStage)

And then implement the `statefulFilterGraphStage` with whatever stateful 
logic you need. The advantage would be that you don't need to manage 
asynchronous future completion in the single stage.

Would that work?

Johannes

On Friday, September 16, 2016 at 9:52:20 AM UTC+2, Simon Lam wrote:
>
> Hello!
>
> I would like to build a custom GraphStage that essentially filters out 
> elements based on a comparison made against the result of a Future and 
> would like to retain this value for future elements.  Additionally, I would 
> also like to preserve the order in which elements pass through filter.  My 
> current implementation uses mapAsync with parallelism factor set to 1 and 
> an actor that executes the future and maintains state.  It pipes results 
> back to self for processing and then sends it back to the temp sender 
> created in the mapAsync call.  Is this approach appropriate?
>
> Would you be able to provide any high level guidance on how to accomplish 
> this in a custom GraphStage?  I think I grasp how AsyncCallbacks work but 
> am not 100% sure about how to guarantee order.  If I execute separate 
> Futures for each upstream push, there is the chance they may finish out of 
> order? 
>
> Any advice is greatly appreciated - thank you in advance!
>

 

-- 
>>  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: Trigger some logic at the moment of TCP connection established

['Johannes Rudolph' via Akka User List]

Hi Yaroslav,

no worries, this is a good question. It depends a bit on what kind of logic 
you want to trigger. If you just want to do something, you can use 
`mapMaterializedValue` to do something with the `OutgoingConnection` object 
before materialization is complete.

If you want to prepend some bytes to be output to the connection, you can 
do it like this:

Flow[ByteString]
  .prepend(Source.single(ByteString("hello connection"))) // or any other 
source
  .via(Tcp(system).outgoingConnection(???, ???))

More complex behavior can be built e.g. by wrapping the complete connection 
flow with a custom GraphStage that would be able to receive all kinds of 
signals.

HTH
Johannes



On Thursday, September 15, 2016 at 12:32:02 PM UTC+2, Yaroslav Klymko wrote:
>
> Either my question is silly or there is no easy answer.
>
> On Saturday, September 10, 2016 at 3:57:33 PM UTC+3, Yaroslav Klymko wrote:
>>
>> Hi guys,
>>
>> I'm trying to figure out on how to trigger some logic at the moment TCP 
>> connection established, and preferably *before traffic goes*
>> Initial code looks like this:
>>
>>
>> Tcp(system).outgoingConnection(???, ???).join(flow).runWith(source, sink)
>>
>>
>>
>> As far as I can see I need to access Future[OutgoingConnection]
>>
>>
>> val outgoingConnection: Flow[ByteString, ByteString, 
>> Future[OutgoingConnection]] = Tcp(system).outgoingConnection(???, ???)
>>
>>
>>
>> So far I came to:
>>
>>
>> val (_, connected: Future[Tcp.OutgoingConnection], _) = 
>> Source.fromGraph(source).viaMat(connection)(Keep.both).toMat(sink)(Keep.both).run()
>>
>>
>>
>> Question 1: how to guarantee my code performed before first ByteString 
>> came?
>> Question 2: is there better solution
>> Question 3: how to prepend connection as first event in the flow of 
>> ByteStrings ?
>>
>>

-- 
>>  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-Streams] Using Framing.delimiter where ByteString stream is part of a Tuple

['Johannes Rudolph' via Akka User List]

Hi Paul,

a combinator to achieve something like this has been proposed several times 
but I think there hasn't been consensus how to implement it exactly. The 
latest approach is discussed here:

https://github.com/akka/akka-stream-contrib/issues/50

Johannes

On Thursday, September 15, 2016 at 8:30:51 AM UTC+2, Paul Brown wrote:
>
> Hi Akka Stream Users,
>
> I'm fairly new to Akka Streams, and only just getting starting 
> understanding some of its concepts. 
>
> One problem I'm having is trying to understand how Tuples are handled in a 
> stream. In my scenario I have a Source emitting Tuple2 of (ZipEntry(), 
> ByteString()). ZipEntry contains basic information (name, date created) 
> about the zip file, and the ByteString contains the extracted text of the 
> zip file.
>
> I'm comfortable getting a stream performing a delimit of a ByteString with 
> the following.
> Source.map(_._2).via(Framing.delimiter(ByteString("\n"), Int.MaxValue)))
>
> However, what I would like to be able to do is maintain the ZipEntry 
> information alongside the ByteString for each new row created through the 
> delimiter. That way I can process the stream further using groupBy etc. 
>
> Example Source --> Sink
>
> Source input:
> (ZipEntry(name1.txt, date1), ByteString(58, 49, ..., 54, 58, ..., 48, 48, 
> ...) )
> (ZipEntry(name2.txt, date2), ByteString(49, 58, ..., 58, 54, ..., 48, 48, 
> ...) )
>
>
> Sink output:
> (ZipEntry(name1.txt, date), ByteString(58, 49, ...) )
> (ZipEntry(name1.txt, date), ByteString(54, 58, ...) )
> (ZipEntry(name1.txt, date), ByteString(48, 48, ...) )
> ...
> (ZipEntry(name2.txt, date), ByteString(58, 49, ...) )
> (ZipEntry(name2.txt, date), ByteString(54, 58, ...) )
> (ZipEntry(name2.txt, date), ByteString(48, 48, ...) )
> ...
>
> Should I be looking at a breaking it down into a RunnableGraph? 
> Any help/pointers to documentation on the correct approach would be 
> appreciated.
>
> Thanks
> Paul
>

-- 
>>  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: Is back pressure triggered upon exceptions

['Johannes Rudolph' via Akka User List]

Hi Kunai,

On Thursday, September 15, 2016 at 7:49:18 AM UTC+2, Kunal Deshpande wrote:
>
> Few questions on back pressure
> 1. While using Flows in akka-streams using .via will a downstream flow 
> apply back pressure to a flow upstream or is back pressure only signaled to 
> a Source?
>

Backpressure is applied everywhere inside of akka-stream and also across 
boundaries using the more generic reactive-streams interfaces (Publisher, 
Subscriber). The details how much backpressure is exactly propagated (or 
which buffers are around) are not so easy to predict, though. Still 
everything in akka-stream should use bounded memory.
 

> 2. Will exceptions in a Flow trigger back pressure
>

No, exceptions will kill the complete materialized flow. Note, that an 
exception propagating through the stream in downstream direction may also 
overtake elements which are buffered but may not have been delivered. 
(Maybe, the question was also "can exception propagation be delayed by 
backpressure" and the answer to that is "no".
 

> 3. Is there a mathematical way to represent back pressure and is it 
> consistent across different reactive streams implementations?
>

I don't know whether someone has already come up with a mathematical model 
of reactive streams semantics. If you read the spec you can see that 
implementations have a lot of freedom of how to implement backpressure 
concretely. E.g. one detail of the akka-stream implementation is that 
akka-stream will request and buffer a few elements at the upstream side of 
an asynchronous boundary. Other implementations may choose other strategies 
how many elements to request in one go.

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

[akka-user] Re: Debugging marshalling implicits

['Johannes Rudolph' via Akka User List]

Hi,

On Tuesday, September 13, 2016 at 4:26:55 PM UTC+2, rrodseth wrote:
> Is this the right way to debug the missing conversion? 
> val prm = implicitly[Future[PimpedResult[(StatusCode, 
Result[StatusDTO])]] => ToResponseMarshallable]


Try 

implicitly[ToResponseMarshaller[Future[PimpedResult[(StatusCode, 
Result[StatusDTO])]]]


then 


implicitly[ToResponseMarshaller[PimpedResult[(StatusCode, 
Result[StatusDTO])]]


then 

implicitly[ToEntityMarshaller[Result[StatusDTO]]] // required by 
APICustomMarshallers.statusMarshaller

or just 

statusMarshaller[Result[StatusDTO]]]


and see which one still succeeds. Then you need to work back from the 
simple ones to the more complex types, trying to get those to work.

HTH
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] Re: Memory leak with akka-streams 2.0.1?

['Johannes Rudolph' via Akka User List]

Hi,

after having a quick look into it (the fully working reproducer was a
great help btw), it turned out that this is indeed a regression
introduced shortly before the release. It is tracked here:
https://github.com/akka/akka/issues/19398

Johannes


On Fri, Jan 8, 2016 at 7:35 PM, Andrey Kuznetsov  wrote:
>> I would like to draw your attention to "akka.stream.FlowShape" class. For
>> this class there are > 64k allocated objects occupying 1.7% of the whole
>> heap size (and of course, this is also cascading to other objects, such as
>> "akka.stream.GraphStageModule", "akka.stream.Outlet",
>> "akka.stream.AbstractStage", "akka.stream.Inlet")
>
> In heap dump we saw the same types occupying unusually lots of memory.
>
> --
>>> 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/8tozN2SX--g/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.



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
>>  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-stream-experimental-1.0] How to reuse akka.stream.scaladsl.Tcp connections?

['Johannes Rudolph' via Akka User List]

On Wed, Aug 26, 2015 at 2:02 AM, Simon Schäfer m...@antoras.de wrote:
 The only thing I didn't understand was this part:

   Source.actorRef(1, OverflowStrategy.fail)

 When I replace the 1 with a 0 (which is allowed according to the
 documentation) I get this error message: Dropping element because there is
 no downstream demand

 Why do I get it? I expected that since there is a client which awaits for
 data that I don't need a cache. Maybe it is because the client (connected
 over TCP) is not a reactive stream, i.e. didn't tell beforehand that it
 awaits data?

If you use `Tcp.outgoingConnection` you get a reactive stream
interface for a TCP connection. On the outgoing stream side it works
like this: whenever there's space in the OS send buffer for the socket
the sink/subscriber part of the flow will tell its publisher that it
needs demand. On a fresh or idle connection this will be the case. So,
I think you are right that a value of `0` could work. However, all
these components are working asynchronously, so you might be running
into a race condition where demand just has not been registered yet.

 Anyway, 1 seems to be enough, even for 100s of requests.

Yes, this is possible. Without load on the machine and especially
testing against localhost the kernel send buffers for a socket are
quite big (I forgot about how big exactly, but usually somewhere
between 100kb and 5MB). It is unlikely that you will be able to fill
the socket buffers fast enough. However, there's still the race
condition of demand having to travel fast enough through the
asynchronous stages, so it could also be just luck that it is working
well right now (or it could mean that your current running conditions
are favorable for this case for unknown reason).

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.

Re: [akka-user] Re: akka streams 1.0 and http routing - in java

['Johannes Rudolph' via Akka User List]

Hi paweł,

yes, that's an unfortunate detail of the Java API. Whatever you put in
there as the Object value it will be ignored. So, to convert your flow
you should be able to use `.ObjectmapMaterializedValue(m - m)` to
convert the type.

Johannes


On Tue, Aug 25, 2015 at 11:19 PM, paweł kamiński kami...@gmail.com wrote:
 OK I give up again :)

 so if I have

 SourceInteger, BoxedUnit source = producer.produce(10, 100);


 and encoder that transforms integer to ByteStrings


 final FlowInteger, ByteString, BoxedUnit encoder = Flow
 .of(Integer.class)
 .map(number - {
 final ByteStringBuilder builder = new ByteStringBuilder();
 builder.putByte((byte) 4);
 builder.putInt(number, ByteOrder.BIG_ENDIAN);

 return builder.result();
 })
 .named(encoder);


 I apply transformation as SourceByteString, BoxedUnit data =
 source.via(encoder) but how do I get SourceByteString, Object data.


 Flow.of(Integer.class) creates Flow that materializes to BoxUnit


 what Object stands for?


 On Tuesday, 11 August 2015 09:44:15 UTC+2, Johannes Rudolph wrote:

 Hi paweł,

 you are on the right track. You need to provide the data as a
 `SourceByteString, Object`. Then, you can create a response like this:

 SourceByteString, Object data = ...
 HttpResponse response =
 HttpResponse.create().withEntity(HttpEntities.createChunked(contentType,
 data));

 If you know the length of the data (i.e. the aggregated number of octets
 in all the ByteStrings the Source provides), you can also use

 HttpEntityies.create(contentType, length, data)

 to create a (non-chunked) streamed default entity.

 HTH
 Johannes



 On Monday, August 10, 2015 at 10:38:40 PM UTC+2, paweł kamiński wrote:
 hi,
 probably again I ve overlooked it in documentation but I cannot find a way
 to respond to a http request with streamed response. probably
 HttpEntityChunked should be used but again I cannot figure out how to set
 entities and flows correctly.


 this is basic example


 private RouteResult getEvents(RequestContext ctx)
 {

 final SourceInteger, BoxedUnit source = producer.produce(10, 100);
 return ctx.complete(HttpResponse.create());
 }


 thanks for any hint on that

 --
 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/kHNRr-Vqhzc/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

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

['Johannes Rudolph' via Akka User List]

Thanks Adam.

On Tue, Aug 18, 2015 at 4:01 PM, Adam Shannon adam.shan...@banno.com wrote:
 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


 --
  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 a topic in the
 Google Groups Akka User List group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/akka-user/Ml1pM652_e8/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Can't find akka.http.javadsl.testkit.JUnitRouteTest?

['Johannes Rudolph' via Akka User List]

Hi John,

how can we know? You need to share more of your code :)

Johannes

On Tue, Aug 11, 2015 at 11:01 AM,  john.vie...@gmail.com wrote:
 I am using Akka http Test

 HttpRequest request = ...
 TestResponse response = appRoute.run(request);

 Unfortunatly TestResponse is null.
 I think its because I am getting  the error No such instance method:
 'akka.http.scaladsl.util.FastFuture'

 Did I compile  wrongly?




 Am Dienstag, 11. August 2015 09:49:29 UTC+2 schrieb Johannes Rudolph:

 Hi john,

 it seems that this is a bug that we thought to be fixed but which has
 reappeared. I filed it as https://github.com/akka/akka/issues/18178

 Johannes

 On Tuesday, August 11, 2015 at 7:08:44 AM UTC+2, john@gmail.com wrote:

 Ok I realized that it is in the release-2.3-dev branch.

 I can create out of the box with sbt package a 2.10
 akka-http-testkit-experimental_2.10 version.
 but I need a 2.11 version.

 Can somebody help? With just java know-how I have no idea how to make a
 2.11 package

 Am Montag, 10. August 2015 23:05:39 UTC+2 schrieb john@gmail.com:

 I wanted to use akka.http.javadsl.testkit.JUnitRouteTest. But I can only
 find the scala dsl  one in akka-http-testkit-experimental_2.11?

 If its not ready can I use the scala one from java?

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



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Akka-http websockets connection fails 95% of the time

['Johannes Rudolph' via Akka User List]

Hi Luc,

in the new dump there are again these two connections:

port 59385 - 57649

and

port 59386 - 8080

It looks as if you are running some kind of transparent proxy (a
desktop firewall sofware?) that redirects all the traffic through a
middleman. So, if you look at the connection from 59385 (the browser?)
it indeed directly sends the packets. However, on the second
connection all these data is buffered for 6 seconds before it is
relayed to the actual server at 8080.

Johannes



On Tue, Jul 28, 2015 at 7:38 PM, Luc Klaassen luc.klaas...@gmail.com wrote:
 I've added a new pcap file, again while sending pings each second, and this
 time i also captured the initial connection. Again it sends all initial
 requests at once after a few seconds (this time 6 seconds)

 I honestly have no idea what the other connections are that can be seen. I'm
 guessing it's some old leftover stuff from previous projects, or something
 running in the background. I guess this is also what's causing the problems
 since noone else seems to have them. (this still doesnt explain why the chat
 application works though, or why without sending pings the message never
 gets sent)

 Op dinsdag 28 juli 2015 08:16:09 UTC+2 schreef Johannes Rudolph:

 Hi Luc,

 On Mon, Jul 27, 2015 at 8:23 PM, Luc Klaassen luc.kl...@gmail.com wrote:
  If you check the git repository, i made some dumps with rawcap (to be
  able
  to capture localhost tcp).

 Thanks. I wonder if you are running servers on different ports? Why
 are there servers running on ports 8080, 55175, and 49162 in the
 dumps?

  The messages are simply not being sent for some
  reason.

 I only see this in the connection to 8080 (dumpfile.pcap). In the
 other connection to the server on port 49162 (dumpfile.pcap) several
 frames are sent by the client but never answered. In the connection to
 port 55175 (dumpfile-ping.pcap) I also see all of the data to be sent
 ny the client immediately but the responses are delayed and only
 dispatched much later (starting with second 23) in one go.
 dumpfile-ping.pcap is unfortunately missing the connection
 establishment and mixes in some other connection as well so it's
 really hard to see what's really going on.

 --
 Johannes

 ---
 Johannes Rudolph
 http://virtual-void.net



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Akka-http websockets connection fails 95% of the time

['Johannes Rudolph' via Akka User List]

Hi Luc,

in that case, can you provide a more information about the kind of
system you are running on? And it would be nice if we had a
tcpdump/wireshark dump that shows what's going on, so we can see at
least at which side things start to go wrong?

Johannes


On Mon, Jul 27, 2015 at 5:19 PM, Luc Klaassen luc.klaas...@gmail.com wrote:
 I've tried your suggestion, but i'm afraid it doesn't change anything. When
 the connection succeeds it will log the message and return, otherwise
 nothing is logged server side, so no other TextMessage or BinaryMessages
 received.

 Luc

 Op maandag 27 juli 2015 17:03:50 UTC+2 schreef Johannes Rudolph:

 Hi Luc,

 On Mon, Jul 27, 2015 at 4:49 PM, Luc Klaassen luc.kl...@gmail.com wrote:
  The connection does not give an error on the client side, but each time
  a
  message is sent it should print the message server side and then return
  a
  response with the reversed string. None of this is happening most of the
  time. It simply says the websocket connection is open, and none of the
  messages that are sent are received server-side.

 Thanks for confirming. That's not what I observe, for me it seems to work.

 However (also, as hinted on the SO issue) your use of `collect` is a
 risk as it won't work in all cases. A message is not guaranteed to be
 strict, so you may miss streamed messages (see [1]). Try

 def websocketActorFlow: Flow[Message, Message, Unit] =
   Flow[Message].mapConcat{
 case TextMessage.Strict(msg) =
   println(msg)
   TextMessage.Strict(msg.reverse) :: Nil

 case other: TextMessage =
   println(sGot other text $other)
   other.textStream.runWith(Sink.ignore)
   Nil

 case other: BinaryMessage =
   println(sGot other binary $other)
   other.dataStream.runWith(Sink.ignore)

   Nil
   }

 and see if you get streamed messages some times. If you get a
 non-strict `TextMessage` you either need to handle it in a streaming
 fashion or you need to buffer the complete message and only run your
 processing, then, on the aggregated string. The second alternative has
 the usual risk of using unbounded memory.

 That said, I guess that we could need some convenience helpers that
 would help with aggregating messages allowing you to specify the
 maximum number of characters and maximum duration for which the
 aggregation should run per message.

 Johannes

 [1]
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0/scala/http/routing-dsl/websocket-support.html#Model



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Akka-http websockets connection fails 95% of the time

['Johannes Rudolph' via Akka User List]

Hi Luc,

I can see the log messages you are seeing:

[DEBUG] [07/27/2015 12:01:01.059]
[api-akka.actor.default-dispatcher-9]
[akka://api/user/$a/flow-47-3-publisherSource-prefixAndTail]
Cancelling akka.stream.impl.MultiStreamOutputProcessor$SubstreamOutput@eda0238
(after: 5000 ms)

but I don't see any connections failing. In which way do you observe
connections to fail?


-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

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

['Johannes Rudolph' via Akka User List]

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.

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

['Johannes Rudolph' via Akka User List]

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.

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

['Johannes Rudolph' via Akka User List]

Hi Adam,

yes, that makes sense. The regression was only present in RC4 and
introduced with commit d6670db48857af9797e271549750f38b223f4483.

Johannes


On Mon, Jul 20, 2015 at 4:39 PM, Adam Shannon adam.shan...@banno.com wrote:
 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 a topic in the
 Google Groups Akka User List group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/akka-user/_fG27EJCZJA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Connecting over Https using Akka-Http client

['Johannes Rudolph' via Akka User List]

Hi Jeroen,

On Thu, Jul 16, 2015 at 4:05 PM, Jeroen Rosenberg
jeroen.rosenb...@gmail.com wrote:
 Anyways, it's working as expected. I do have one small unrelated issue. The
 stream I am consuming is in Gzip format, so I'm unzipping the ByteStrings as
 they come in as part of my FlowGraph. However, when I try to unzip the
 ByteString coming out of the response.entity.dataBytes source I'm getting
 errors on the Gzip format. As if the Chunks I'm getting are incomplete.

Can you show some code? Are you using
`akka.http.scaladsl.coding.Gzip`? If not, can you try if that works?
You should be able to either use `Gzip.decode(response)`,
`Gzip.decode(response.entity)`, or use `Gzip.decoderFlow` manually.

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.

Re: [akka-user] Re: Connecting over Https using Akka-Http client

['Johannes Rudolph' via Akka User List]

Hi Jeroen,

On Thu, Jul 16, 2015 at 4:35 PM, Jeroen Rosenberg
jeroen.rosenb...@gmail.com wrote:
 def gunzip(bytes: Array[Byte]) = {
   val output = new ByteArrayOutputStream()
   FileUtils.copyAll(new GZIPInputStream(new ByteArrayInputStream(bytes)),
 output))
   output.toString
 }

This creates a new GZIPInputStream for every chunk (incidentally: how
the chunks are cut is not under your control). However, gzip
compression is stateful and recreating the GZIPInputStream will reset
the state every time you create a new instance. Therefore, it cannot
work as simple as this.

The `Gzip.decoderFlow`, in contrast, keeps this state between chunks.

-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

-- 
  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: Connecting over Https using Akka-Http client

['Johannes Rudolph' via Akka User List]

Hi Jeroen,

it would be very helpful if you could somehow come up with a
reproducer against some publicly accessible endpoint which would show
the issue. It seemed to work for all the URLs I tested.

Johannes

On Wed, Jul 15, 2015 at 6:25 PM, Jeroen Rosenberg
jeroen.rosenb...@gmail.com wrote:
 Btw,

 I tried connecting to the stream using plain old java.net.HttpUrlConnection

 val connection = new java.net.URL(...).openConnection()

 // set headers
connection.getInputStream
connection.getResponseCode

 this way it just works and I get status code 200. So it seems something goes
 wrong in akka http.

 Jeroen

 On Wednesday, July 15, 2015 at 5:01:32 PM UTC+2, Jeroen Rosenberg wrote:

 Thnx Johannes for the swift reply :)

 I'm using JDK 7. I strongly suspect the host I connect to
 (stream.gnip.com) to be a virtual host (as they also provide other endpoints
 such as api.gnip.com). I just tried with 1.0 and it gives me the same
 result.

 Jeroen

 On Wednesday, July 15, 2015 at 4:47:10 PM UTC+2, Johannes Rudolph wrote:

 Hi Jeroen,

 is this a virtual host you are connecting against? This may hint towards
 the client not sending the TLS SNI extension correctly which could be a bug
 in akka-http or due to an old JDK version on your client. Which JDK version
 do you use?

 https://en.wikipedia.org/wiki/Server_Name_Indication says that you would
 need at least JDK 7 to make SNI work (only relevant if the host you connect
 against is an HTTPS virtual host).

 Also, you could try the just released 1.0 version (though I cannot think
 of a reason why that should fix it).

 Johannes

 On Wednesday, July 15, 2015 at 4:13:14 PM UTC+2, Jeroen Rosenberg wrote:

 I'm trying to connect to a third party streaming API over HTTPS using
 akka-stream-experimental % 1.0-RC4 and akka-http-experimental %
 1.0-RC4

 My code looks like this

 class GnipStreamHttpClient(host: String, account: String, processor:
 ActorRef) extends Actor with ActorLogging {

   this: Authorization =


   private val system = context.system

   private val endpoint = Uri(shttps://$host/somepath;)

   private implicit val executionContext = system.dispatcher

   private implicit val flowMaterializer: Materializer =
 ActorMaterializer(ActorMaterializerSettings(system))


   val client = Http(system).outgoingConnectionTls(host, port, settings
 = ClientConnectionSettings(system))


   override def receive: Receive = {

 case response: HttpResponse if response.status.intValue / 100 == 2
 =

   response.entity.dataBytes.map(processor !
 _).runWith(Sink.ignore)

 case response: HttpResponse =

   log.info(sGot unsuccessful response $response)

 case _ =

   val req = HttpRequest(GET,
 endpoint).withHeaders(`Accept-Encoding`(gzip), Connection(Keep-Alive)) 
 ~
 authorize

   log.info(sMaking request: $req)

   Source.single(req)

 .via(client)

 .runWith(Sink.head)

 .pipeTo(self)

   }

 }


 As a result I'm getting an Http 404 response. This doesn't make much
 sense to me as when I copy the full url to curl it just works

 curl --compressed -v -uuser:pass https://my.streaming.api.com/somepath


 Also when I connect to a mock implementation of this streaming API using
 Http protocol, my code works fine (using outgoingConnection instead of
 outgoingConnectionTls).

 What do I do wrong when making Https request? As far as I understand
 changing to outgoingConnectionTls should be enough for most cases.

 Any help is be appreciated!

 --
 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/kqFup-bylUg/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.



-- 
Johannes

---
Johannes Rudolph
http://virtual-void.net

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