Hi Doru, Based on what I've seen (but of course may be criticized by others) I don't know if there is a sufficient reason to <not> use the REST API and use something else instead. What is your concern? Network traffic? AFAIK if localhost is bound to lo or something similar, that isn't an issue. As for your question about indexing your data before sending into ES, IMO that is what the Logstash examples illustrate. The little 5-node ES cluster lab cluster I setup running ES, Redis, logstash and netcat as described in the Logstash 10-minute walkthrough was interesting re your question about separating load on to different apps running in different consoles. I could observe the apache data as it progressed through each app (because logstash was configured with a stdout output). I could see if there was a pause here and there, possibly indicating unused capacity. I recommend you look at that tutorial and see if it answers your questions as well. IMO, Tony
On Monday, February 10, 2014 7:58:59 AM UTC-8, Doru Sular wrote: > Hi guys, > > I intend to use the elasticsearch embedded in my webapplication. > Is there a kind of optimization for rest calls (for indexing a document > for example) to not generate http traffic, when the elasticsearch is > running in same virtual machine as the service caller? (Instead of generate > an http request, just use java objects) > Is there a way to index a document without using the rest api, in case the > elasticsearch is embedded in the same webapplication? > I want to index the log messages from my application as soon they are > produced, but we have a lot of messages, should I be concerned of the http > loading on the server? > > Thank you very much, > Doru > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4c976cf9-1526-4e24-ac5f-187bb7e7e0d1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
