Hi Magnus,
On Wed, Dec 24, 2014 at 11:55 AM, Magnus Andersson < [email protected]> wrote: > Hi > > Thanks for the clarification. > > Actually the HTTP Connection is done in the 'con' flow, not in > proxyBranch. But that does not matter, the end result is still the same. > > It confirmed my suspicion: If I want a connection to only establish the > connection in the success branch is taken, I have to make a sub flow. > Yes but if you use something similar to my snippet then this is completely transparent to the surrounding graph, since my snippet is still a Flow[Request, Response]. Once we add new features to the Http client you will be able to drop this workaround flow and inject the proper pooled connection client flow instead. One more reason to make your graphs and flows modular. > > Then I have a follow up question: What would be the recommended way if I > would want to make a file upload, but for only authenticated users, without > initiating any upstream connections before authentication is done? > This is a bit tricky right now. You can use mapAsync with the ask pattern and use an actor on the side to add authentication logic. This might work or not depending on how your authentication protocol works. > > How would the syntax look for feeding the chunks to the upstream storage > when having a sub flow and keeping backpressure. Or can you see a smarter > solution, that completely avoids sub flows? > You can hide sub-flows similar that I did in my snippet (by flattening them out). Also, nothing stops you from using actors if a particular sub-problem does not fit streams. -Endre > > Again happy holidays. Thanks for the Streams documentation present nicely > before Christmas. :) > > /Magnus > > Den onsdagen den 24:e december 2014 kl. 09:48:43 UTC+1 skrev drewhk: >> >> Hi Magnus, >> >> >> >> On Wed, Dec 24, 2014 at 1:55 AM, Magnus Andersson < >> [email protected]> wrote: >> >>> Hi >>> >>> I am building a simple reverse proxy as an exercise to understand Akka >>> Streams. I have read the new docs but could not find an answer. >>> >>> I'm using FlexiRoute as recommended in an earlier thread to determine >>> when my Akka HTTP service should proxy to the remote service and when not >>> to. But even if the flow does not go through the reverse proxy part of the >>> graph, I still see a remote connection established in the logs. This >>> happens every single time, regardless of input request. >>> >> >> Yes, all Flows are materialized when you materialize the container graph. >> Flows representing connections do the actual connect when you materialize >> them. >> >> >>> >>> How do I avoid this behaviour? >>> >> >> The "connect-when-materialized" is by design. >> >> >>> I only want the connection to be established when that part of the graph >>> flow is executed. >>> >> >> Your problem of timed out connections will happen anyway even though a >> first message was sent through, after not receiving a new message for a >> while. If I assume that proxyBranch is using HttpClient then I guess we are >> talking about functionality that is not there yet (pooled connections a la >> Spray), the current API as far as I know is just using a single TCP >> connection. >> >> Alternatively you can use "mapAsync{ req => Source.single(req).via(Http(). >> outgoing.flow).runWith(Sink.head) }" which edge will materialize a new >> outgoing proxy flow for each request instead of reusing a statically >> materialized flow. Probably a bit less efficient, but will avoid your >> problems. >> >> -Endre >> >> >>> >>> This is the flow graph setup: >>> >>> val partialBranch = PartialFlowGraph { >>> implicit b ⇒ >>> import FlowGraphImplicits._ >>> val route = new BranchRoute[HttpRequest] >>> val merge = MergePreferred[HttpResponse] >>> in ~> proxyBranch ~> route.in >>> route.success ~> proxyTo ~> con ~> merge >>> route.failure ~> badRequestFlow ~> merge.preferred >>> merge ~> out >>> } >>> >>> >>> Please see this gist for a fully working example: >>> https://gist.github.com/magnusart/bffe1a15dab30f794235 >>> >>> Oh, and merry christmas! :) >>> >>> /Magnus >>> >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> -- > >>>>>>>>>> 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. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
