HI Frederic,
First I would like to say I'm a big fan of akka-http. It's really a great > framework and I'd like to thank you all for making such a great product. > Thank you, we are trying to make it better! > > In akka-http documentation there's a big caution I'm experimenting : > > Caution: When you receive a non-strict message from a connection then >> additional data are only read from the network when you request them by >> consuming the entity data stream. This means that, if you don’t consume >> the entity stream then the connection will effectively be stalled. In >> particular no subsequent message (request or response) will be read from >> the connection as the entity of the current message “blocks” the stream. >> Therefore you must make sure that you always consume the entity data, even >> in the case that you are not actually interested in it! > > > When you use the client high level API it is very error prone to forget to > drain when, for exemple, you only need to check the status code, or when > you pattern match an don't have the expected Status code you may forget to > drain some 404 bodies for exemple > > I saw many people posting about this subject so I'm wondering about this > trapping API. > We are aware of the issue and have a ticket for it actually: https://github.com/akka/akka/issues/18716 In many cases we can probably handle this for users, because currently even us can forget to do it. That ticket is for the server-side though. > > > Is there a simpler (or more standard) way ? > > As this issue is recurrent shouldn't we have a more secured way to handle > this ? a kind of lean pattern that garanties that all resources are > properly released ? > Well, loan pattern won't work, because the running stream is on another thread, i.e. the ownership outlives the calling scope (yay, Rust terminology infects me slowly...). > I'm looking for, but haven't found yet, a more simple method like dummy > <- response.ignoreData that does this in a more simple way? > What would force people to do everything properly would be to give back the strict parts of the message (request/response) as the materialized value for the lazy part, since this would mean that practically you would always need to materialize to do anything. It would not be a nice API though :( > > My second question is : > > I'm implementing a proxy base on akka-http > I was surprised by a non obvious and tricky implicit at High-Level API > > Here's a simplified version of the code after the request being updated to > the new target : > > def forward : Route = { (context: RequestContext) => > val futureResponse: Future[HttpResponse] = > Http().singleRequest(context.request) > futureResponse.fast.transformWith{ > case Success(res: HttpResponse) ⇒ > context.complete(res) > case Failure(error) ⇒ context.complete(StatusCodes.InternalServerError, > s"An error occurred: ${error.getMessage}") > } > }} > > > It seamed to me natural to pipe the client side HttpResponse in the > incoming request using .complete. But what happens in the underlying layers > is that the HttpResponse is marshalled in an intermediate representation > that may produce a valid HttpResponse at the end. > > In fact this only works with HttpEntity.Strict > The same problem of stalle connection will be produced by HttpEntity. > Chunked > > I have to admit it was surprising to me to discover that this implicit > conversion that takes an httpResponse and that finally will produce an > other HttpResponse don't drain properly > > I saw some other sample of proxy at lower level like this : > https://gist.github.com/rklaehn/3aa3215046df2c0a7795 > but I would prefer stay at Higher-Level API > > Could you give me advice about this point. > Should I implement a Marshaller > Should I use a lower level of api (I would like to use a connection pool) > An other way ? > I would go with the lower level API for the proxying (you can still use the DSL for other paths), but I think you should open a ticket about proxying in the DSL in general, since there are cases where your service in turn calls an internal service via its HTTP API, and this means essentially proxying (with some transformations maybe). -Endre > > > Thanks a lot for your advices and for the great job done > > Fred > > -- > >>>>>>>>>> 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 https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - Reactive apps on the JVM 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
