Non-blocking Future

[guersam]

Hi, I'm looking for an ES client and your DSL-based approach looks very promising. Thanks in advance :)

One thing makes me worry is about the current execute implementation.

https://github.com/sksamuel/elastic4s/blob/master/src/main/scala/com/sksamuel/elastic4s/Client.scala#L39-L41

It takes per-client ExecutionContext and returns a Future by wrapping blocking actionGet() with a future {} block. It doesn't block the current thread but actually blocks the dedicated one, so it might reduce overall throughput and be a bottleneck.

Suggestion is attaching an ActionListener[T] using this and returning a Future from our own Promise, for example (not tested, just a concept):

def execute[A <: ActionRequest, B <: ActionResponse, C <: ActionRequestBuilder[A, B, C]](action: Action[A, B, C], req: A): Future[B] = {
  val p = Promise[B]()
  client.execute(action, req, new ActionListener[B] {
    def onResponse(response: B) = p.success(response)
    def onFailure(e: Throwable) = p.failure(e)
  })
  p.future
}

It'll make the API require an ExecutionContext for every request. If you accept this change I'll open a PR when time allows.

[sksamuel]

I guess the idea is you can pass in your own execution context if you think it might become a bottleneck.

If we move to using a Promise that we complete using an action listener, then the bottleneck moves to the underlying elasticsearch client executor, right? If so, what's the advantage?

I'm not against the idea of doing it this way, I just need to better understand the advantage.

[guersam]

ES java client manages it's own thread pool. If we make a blocking call in a single client-wide ExecutionContext, the intermediate thread will be blocked and the ES thread pool won't be fully utilized.

[sksamuel]

I see that we are thinking about slightly different cases.
I am using the case that people will use the client as a non data node (using transport client for example), in which case the client has its own thread pool that is no different to the a thread pool you can specify to the e4s client. I think you're using the case where your client is also a data node, in which case using ES's own thread pool might be better.
Perhaps we can solve this by adding in the callback methods you suggest, but keeping the "internal thread pool" ones as well? What do you think ?

[guersam]

In usual, when you send an async request via a transport client, it registers a callback on it's internal thread pool and the pool will notify when it's done. Additional requests will be handled in the same manner.

However, by blocking request inside a shared execution context, additional ones won't be sent until the previous one is done and the thread pool will hold only one request at once like this:

[guersam]

There should be Elastic4s client between 'User' and 'ExecutionContext'..

[sksamuel]

Yes I see what you mean. I'll follow up tonight with some conversion work, or you can start on a branch if you want.

[sksamuel]

take a look over what I've done, feedback very much welcome.

[guersam]

Thanks :) I'll send a following PR in a few days.