Hi Ivan,
We mainly have 2 uses cases to wrap ES ListenableActionFuture:
Use case 1:
We have built a library that maps entities and their relationships to ES.
It is very similar to JPA, the main difference is that the target is ES and
not a relational db. Also all methods are async and return a guava
ListenableFuture.
As an example, lets take the method that returns a single entity. Here is
its signature:
public ListenableFuture get(Class cls, String id);
Internally this method does the following:
- Calls client.prepareGet(index, type, id).execute(); --> this returns a
ListenableActionFuture
- Registers a listener on the listenableActionFuture so itś non blocking
- When the listener is called we convert the json to the correct Java
object(along with its relationships eagerly or lazily loaded if we asked
for it, but that is a different story)
This code is working fine but it would be much easier if ES
ListenableActionFuture could subclass guava ListenableFuture.
In essence we would then simply use guava Futures.transform(xx, xx) that
applies a function to the ListenableFuture to transform the json to a java
object
Less boilerplate code to write.
Use case 2:
In some other part of our application, we call ElasticSearch (lets say a
simple get by id), then we call another service containing extra data for
the same id.
Both calls are async. When we get both result, we simply need to stuff
the json of the second call into the json we got from ES. of course the
result is itself a ListenableFuture.
Once again here, it's quite a bit of code that's not easy to read, to make
it work.
In both cases, it's fairly painful to transform/chain ES
ListenableActionFuture.
Concerning guava, you are right, ES already uses it. It inlines some(all?)
google guava code. Actually I believe that quite a bit of the concurrent
code comes from guava. So subclassing guava ListenableFuture should not be
a problem. But this will of course make the internal guava ListenableFuture
part of the ES api..
To summarize, I believe that there is a need to make ES
ListenableActionFuture easily chainable/transformable.
It can be achieved by
- subclassing guava ListenableFuture
- converting ES ListenableActionFuture to guava ListenableFuture (although
this one seems trickier because guava allows listeners to run different
threads)
Stephane
On Wednesday, April 17, 2013 7:42:59 PM UTC+2, Ivan Brusic wrote:
After having used Scala, I love the power and flexibility of using
Futures. I have not had a use case to do any transformations with
ElasticSearch futures, but it would be interesting to see.
ElasticSearch uses Guava for the field caches. Not sure if there are
any other uses.
--
Ivan
On Wed, Apr 17, 2013 at 12:21 AM, Stephane Bastian
stephane.b...@gmail.com wrote:
Hi,
I've been using ES for almost 2 years now and I'm very pleased with
it. I am especially happy with the fact that everything is Asynchronous.
However, the one thing that sometimes gets in the way is when the
code calling ES has some logic to transform, chain or compose several
ListenableActionFuture.
Outside ES, we are using google Guava to solve these tricky
problems and make extensive use of Futures.transform (to transform a
ListenableFuture in another ListenableFuture) or Futures.allAsList, etc.
For people that have no clue of what I am talking about ->
ListenableActionFuture returned by ES are great but there are no
helper methods to transform, chain, group ListenableActionFutures.
So the question is:
How about modifying ListenableActionFuture so that it extends
ListenableFuture from Guava? This would allow for super simple integration
with Guava concurrent package.
Another question for my own curiosity:
Do you use google guava with ES?
Cheers!
Stephane
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to elasticsearc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.