search

WikiWatershed / mmw-geoprocessing

A Spark Job Server job for Model My Watershed geoprocessing.
Apache License 2.0
6 stars 6 forks source link

Collections API: Reduce Blocking #67

Closed rajadain closed 6 years ago

rajadain commented 6 years ago

Currently, the model calls seem to be blocking, so when faced with a large long-running requests, shorter requests have to wait for them to finish.

Investigate returning a Future instead, so the requests can be made lock-free.

kellyi commented 6 years ago

For reference: http://doc.akka.io/docs/akka-http/10.0.9/scala/http/handling-blocking-operations-in-akka-http-routes.html

mmcfarland commented 6 years ago

See related comment in original issue: https://github.com/WikiWatershed/mmw-geoprocessing/issues/47#issuecomment-316501936

hectcastro commented 6 years ago

Even with blocking operations within the scope of a single request/response cycle, we should be able to handle multiple requests in parallel due to the thread pool managed by Akka HTTP to handle connections. You're saying that things block at 2 requests, or when the Akka HTTP thread pool is saturated?

kellyi commented 6 years ago

From a comment on #47 (here https://github.com/WikiWatershed/mmw-geoprocessing/issues/47#issuecomment-325742599):

My suggestion for further optimization is to use Futures for fetching layers in parallel. This would mean changing this method to return a Future[Seq[TileLayerCollection[SpatialKey]]], and spidering the Futures through the codebase. akka-http lets you return a Future from the route, so you could carry the future all the way through to the route.

The comment has more detail, but as part of this issue we should update each of the codepaths to interlace Futures throughout.

rajadain commented 6 years ago

You're saying that things block at 2 requests, or when the Akka HTTP thread pool is saturated?

It felt like it was blocking at 2 requests when given a very large input, but that may be because of CPU overutilization than thread pool saturation.