Hi,
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.
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.
My first question is :
What's the best way to drain the connection when your not interested by the
datas. (a way that should be efficient)
should I do something like this dummy line :
for {
response <- Http().singleRequest(HttpRequest(uri = uri, method =
HttpMethods.DELETE))
dummy <- response.entity.dataBytes.runWith(Sink.ignore) //you have to drain
or the connection will stalle
} yield {
//test status code here
...
}
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 ?
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?
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 ?
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 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.
