On Wednesday, 27 May 2015 14:01:46 UTC+1, rkuhn wrote: > > Maybe I misunderstand you still, but ConnectionManager is not something > that we have in Akka HTTP >
I am referring to the `manager` field in an implementation of `akka.io.IO.Extension`. The limitation that I'm referring to lies with spray-can, in that it cannot handle the WebSockets Upgrade request... presumably akka-http bypasses this because your HTTP manager is more advanced and you are not using spray-can in the first instance. I should very much like to have access to the new HTTP manager so that I can bypass the Streams API for legacy integration with Actors. However, it would appear that you're saying there is no way to use akka-io for HTTP communication in this way, and that is a great shame. The spray-can/http integration with the actor frameworks is fantastic, and the loss of this integration will be sorely missed when it is deprecated. > Just because something is a Flow does not make any promises ... > > > This is not true: a Flow has one open input and one open output port and > all data elements that flow through these ports will do so governed by the > Reactive Streams back-pressure semantics. This means that the Flow has the > ability to slow down the Source that is connected to it and it also reacts > to slow-down requests from the Sink that it will be connected to. > This means nothing if the Source doesn't backpressure properly or the Sink just acks everything. I don't really care about what happens in one component, I care about the entire system. In your new websockets API, the user provides the implementation of the Flow... what I care about is that the framework behaves correctly in their Source and Sink. In particular, I'd like to have confirmation that network packets are only read from the network when the Source is told to progress and that the backpressure callback to the user-provided Flow is only invoked when akka-io has confirmed that it has written the last message to the the network (i.e. the akka-io Ack). Details of these points are *absolutely essential* to the management of the heap and I do not want to simply assume that it is true. With regards to the rest of your comments and suggestions, thanks for that. I shall study it further if I have time to undertake writing a wrapper layer. In the short-term, it looks like the barrier to entry is far too high without a convenient Stream/Actor bridge in place, so I will be sticking with wandoulabs' and smootoo's convenience classes. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
