Hi Samuel and Marek,
Very interesting solutions thanks!
Le mardi 31 mai 2016 08:43:28 UTC+2, Marek Żebrowski a écrit :
>
> Faced with similar problem we went following route:
> 1. increased max connections to 64 for a host - default 4 is ususally way
> to low for high-traffic scenarios
> 2. added a queue that holds incoming requests, with overflow strategy
> DropNew. Yes, it is not perfect solution, but nothing crashes, in worst
> case requests are not handled
>
> val cps = ConnectionPoolSettings(system).withMaxConnections(64
> ).withPipeliningLimit(1).withMaxOpenRequests(64)
>
>
> val clientFlow = Http().cachedHostConnectionPoolHttps[Int](host = "
> mandrillapp.com", settings = cps)
>
>
> val queueFlow = Http().cachedHostConnectionPoolHttps[Promise[
> HttpResponse]](host = "mandrillapp.com", settings = cps)
>
>
>
>
>
> val queue = Source.queue[(HttpRequest, Promise[HttpResponse])](1024,
> OverflowStrategy.dropNew)
>
>
> .via(queueFlow)
>
>
> .toMat(Sink.foreach({
>
>
> case ((Success(resp), p)) => p.success(resp)
>
>
> case ((Failure(e), p)) => p.failure(e)
>
>
> }))(Keep.left)
>
>
> .run
>
> and actual request is done via
>
> val promise = Promise[HttpResponse]
>
>
> val r = request -> promise
>
>
>
> queue.offer(r) flatMap {
>
>
> _ match {
>
>
> case Enqueued => promise.future
>
>
> case _ => Future.failed(new RuntimeException("request not
> enqueued"))
>
>
> }
>
>
> }
>
> whole thing can be seen:
>
> https://github.com/sgrouples/scamandrill/blob/master/src/main/scala/com/joypeg/scamandrill/client/ScamandrillSendReceive.scala
>
> While not perfect solution, it handles both very slow and crashed service,
> without slowing or crashing other parts of the system.
>
> Depending on your use-case you might experiment with different overflow
> strategies, add circuit-breakers, etc.
>
>
> W dniu środa, 25 maja 2016 11:07:04 UTC+2 użytkownik Loïc napisał:
>>
>> HI,
>>
>> I would like to use Akka Http client to call a webservice in a non
>> blocking way.
>> The app that will use this client must never block and should never
>> crash, even if the webservice that it will call becomes very slow (for
>> example if the traffic is too high).
>> When the client registers a callback, I guess it's memorized somewhere,
>> so what is happening if a lot of queries and callbacks are kept in memory
>> because the webservice takes too much time to respond?
>> I guess it can cause some memory issues, so is it possible to cancel and
>> drop some queries when this happens?
>>
>> Thanks :)
>>
>
--
>>>>>>>>>> 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.
