Akka HTTP client overflow strategy

[Loïc Descotte]

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 :)

[Viktor Klang]

Hi Loïc!

Your requirements, if interpreted literally, will be impossible to achieve (as in, in our universe).

On the other hand, if we don't take them all that literally, have you tried it out, with a timeout, and tested different load scenarios?

--
>>>>>>>>>> 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+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

[Loic Descotte]

Hi Viktor,

Thanks for your answer!

I haven't yet done some load test but I will :)

Thanks 

Loïc

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/0QlPEhDzRjo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Samuel Tardieu]

Wouldn't a circuit breaker allow you to drop new queries early if the service takes too long to answer so that they don't accumulate?

http://doc.akka.io/docs/akka/2.4.6/common/circuitbreaker.html

  Sam

--

[Marek Żebrowski]

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.

[Loïc]

Hi Samuel and Marek,

Very interesting solutions thanks!