Ok that's fine for me. I can use 0.19.0-SNAPSHOT.
I will test it and write results here.
I will double check in 0.18, master not longer has this problem, btw, because of different usage of Cache guava (and new versions of guava).
On Thu, Jan 5, 2012 at 6:53 PM, email@example.com firstname.lastname@example.org wrote:
I put index.cache.query.parser.type=none in the same file where I defined the clustername and it didn't change the behaviour.
I can always see one, two then 3 threads org.elasticsearch.common.base.internal.Finalizer and I finally get OOM issues.
Finalizer seems to be one of the first threads launched by ES.
My es property file contains only :
Le 5 janvier 2012 à 14:55, Shay Banon email@example.com a écrit :
Can you try and set index.cache.query.parser.type to none when you start the node in its settings? Thats the only place that uses weak cache.
On Thu, Jan 5, 2012 at 6:56 AM, Michael Sick < firstname.lastname@example.org > wrote:
Wow what a thread! I see this behavior as well. Anyone have a workaround?
On Wed, Jan 4, 2012 at 11:03 PM, Philippe Laflamme < email@example.com > wrote:
Seems to be the Guava "Finalizer" thread issue:
On Wed, Jan 4, 2012 at 15:50, David Pilato < firstname.lastname@example.org > wrote:
I’m playing with an embedded ES node in a webapp deployed in a tomcat container.
ES Node is injected using Spring.
ES is 0.18.5
Tomcat is 7.0.19
Spring is 3.1.0.RELEASE
And I’m launching everything in debug mode from Eclipse.
Everything works fine for the “first launch” but each time tomcat restarts (because something changes in my workspace), it seems that Elasticsearch is not fully “unloaded” before the reload.
So I quickly get OOM errors.
When I look at the running threads, I can see at the first launch one occurrence of
Daemon Thread [org.elasticsearch.common.base.internal.Finalizer] (Running)
After one restart, I can see two of them, and after the third restart, a third occurrence.
It seems to be the only Thread that remains after a Client.close() and Node.close().
Any idea ? Do I have to call another ES method to “destroy” all the ES threads ???
Anything I can do to add more details about this ?
Twitter : @dadoonet