Ah! Causing out of memory exception on node is not the best practice for sure! :-) That's one of the reason I would not put Tika in nodes directly.
One of my TODO item is to move FSRiver to logstash. So extracting content will be done by logstash (probably using Tika) but in a separate process than elasticsearch. So once in, it will be supported in contracts. -- David ;-) Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs Le 18 févr. 2014 à 08:23, [email protected] a écrit : Hi David, Thanks for your answer! It does make sense. The reason for my questions was: I wanted to take advantage of the mapper-attachment plugin, and on the other hand the high availability and scalability features of ElasticSearch nodes to perform the analyzing of the documents. E.g. we have experienced situations where Tika was eating all the memory of a machine, and in the end died… My thought was ElasticSearch could, in these situations, detect and remove the affected node from the cluster. I have no trouble with development but if we can use available software for which we have a support contract then I prefer that way Any thoughts? adTHANKSvance, Jan -- 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/e3f7c3ed-7e94-4f2e-b430-96d72a233f7e%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/1827F995-35E5-4324-8216-AD306A1B8595%40pilato.fr. For more options, visit https://groups.google.com/groups/opt_out.
