Hi Roland, On Wednesday, 27 May 2015 08:18:09 UTC+1, rkuhn wrote: > For this venture you need no HTTP documentation
Actually I'd like to go futher than akka-http and see documentation that allows me to use WebSockets with akka-io directly, bypassing the Streaming API. The historic limitation has always been that the HTTP ConnectionManager of akka-io was unable to handle the upgrade request. Wandoulabs use their own actor to handle HTTP and UHTTP, but it has annoying side effects. I'm interested to know how akka-http has managed to implement WebSockets with that constraint in place (or if that constraint has been lifted). > The statement “there are no promises around back-pressure” > indicates that you did not, in fact, understand the full extent > of what Akka Streams are. Just because something is a Flow does not make any promises about how back pressure is actually implemented in that flow: you have even pointed out how to create "open hoses", or just blow up internal buffers when downstream doesn't consume fast enough. I'd like to know if the underlying Source of incoming client messages on a websocket endpoint will respect the backpressure from the `handleWebsocketMessages: Flow` that is dealing with it (i.e. not read from the network unless `handleWebsocketMessages` is pulling), and conversely if the underlying Sink back to the client is going to backpressure using akka-io's Ack mechanism so that `handleWebsocketMessages` will only be pulled when akka-io gives the green lights. > We’d love to improve the documentation in this regard, but we’d > need to first figure out where their deficiency is, hence I’m > talking with you. I think clarity on the above two points would be a good start. In addition, and more generally, integration between "hoses" and "hammers" is extremely important --- unless you intentionally want to limit akka-streams uptake to green field projects only. The project I work on has 1.2 million lines of Scala code with legacy components dating from Scala 2.6. There isn't a snowball's chance in hell of rewriting it to use akka-streams. >> What I'm missing is the ability to hook an existing actor >> system into something that expects a Flow, with back pressure >> preserved. > > As I hopefully explained in my other mail about hoses: your > Actors would need to implement the full spec, they’d need to be > watertight. This is a start. Is there a test framework that can be used to stress test the implementation of a Stream / Actor bridge? > How we implement Flows internally should be of no consequence On the contrary, I feel the implementation is of huge significance. Firstly, it helps to understand the expected performance, and second it is critical when writing integration code. It is extremely bizarre that both projects should be released under the akka banner, yet be so siloed. > In order to solve this particular problem you’ll need to > carefully describe the back-pressure protocol spoken by your > Actor. The Actor is expecting to send messages directly to akka-io and speaks the akka-io Ack protocol using a simple object as the Ack message. It expects an Ack before it will send a message upstream (and it greedily consumes data, but that could easily be changed). Best regards, Sam -- >>>>>>>>>> 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.
