ElasticSearch Java Client with Spring doesn't stop


(Eugene Strokin) #1

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code here:


I just @Autowire EsClientProvider and everything works fine, except when
application stops, I still have threads running and it hangs, and I need to
kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application
exits, but it doesn't change anything.

Thank you,
Eugene S.


(David Pilato) #2

Yes. It's a pain.
It's relative to this issue : http://code.google.com/p/guava-libraries/issues/detail?id=92

BTW, may I suggest that you gave a look at the ES Spring Project ? : https://github.com/dadoonet/spring-elasticsearch

Cheers
David

Le 13 juin 2012 à 07:53, Eugene Strokin eugene@strokin.info a écrit :

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code here: https://gist.github.com/2922102
I just @Autowire EsClientProvider and everything works fine, except when application stops, I still have threads running and it hangs, and I need to kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application exits, but it doesn't change anything.

Thank you,
Eugene S.


(Eugene Strokin) #3

Thank you David, I'll try spring-elasticsearch out.
Did you find any solution for this hang up problem? I need to run some jobs
periodically which are using ES. I was planing to use cron, but with this
problem, I end up with lots of hanging process. Not acceptable for
production.

Thanks again
Eugene

On Wednesday, June 13, 2012 2:42:07 AM UTC-4, David Pilato wrote:

Yes. It's a pain.
It's relative to this issue :
http://code.google.com/p/guava-libraries/issues/detail?id=92

BTW, may I suggest that you gave a look at the ES Spring Project ? :
https://github.com/dadoonet/spring-elasticsearch

Cheers
David

Le 13 juin 2012 à 07:53, Eugene Strokin a écrit :

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code
here: https://gist.github.com/2922102
I just @Autowire EsClientProvider and everything works fine, except when
application stops, I still have threads running and it hangs, and I need to
kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application
exits, but it doesn't change anything.

Thank you,
Eugene S.


(David Pilato) #4

No. I did not try to find a solution as Google said at first that the issue was
closed. Shay gets in the 0.19 branch the last version of Guava. But then the
issue was reopened... :frowning:
I'm not sure that there is a solution actually...

Also, in production, by now, each time I push a new version of my project, Sysop
team restart my jboss instance. So I don't really have Threads remaining.

But it's really a pain when you want to debug under tomcat as each time tomcat
restart, I get OOM exceptions...

You said that you run jobs using cron. That means that you start each time a new
jvm and stop it after the end of the job ?
If so, it should not be a problem for you as you kill the java process...

David

Le 13 juin 2012 à 18:12, Eugene Strokin eugene@strokin.info a écrit :

Thank you David, I'll try spring-elasticsearch out.
Did you find any solution for this hang up problem? I need to run some jobs
periodically which are using ES. I was planing to use cron, but with this
problem, I end up with lots of hanging process. Not acceptable for production.

Thanks again
Eugene

On Wednesday, June 13, 2012 2:42:07 AM UTC-4, David Pilato wrote:

Yes. It's a pain.
It's relative to this issue :
http://code.google.com/p/guava-libraries/issues/detail?id=92

BTW, may I suggest that you gave a look at the ES Spring Project ? :
http://code.google.com/p/guava-libraries/issues/detail?id=92
https://github.com/dadoonet/spring-elasticsearch

Cheers
David

Le 13 juin 2012 à 07:53, Eugene Strokin a écrit :

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code
here: https://github.com/dadoonet/spring-elasticsearch
https://gist.github.com/2922102
I just @Autowire EsClientProvider and everything works fine, except
when application stops, I still have threads running and it hangs, and
I need to kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application
exits, but it doesn't change anything.

Thank you,
Eugene S.
https://gist.github.com/2922102

https://gist.github.com/2922102

--
David Pilato
http://dev.david.pilato.fr/
Twitter : @dadoonet


(Shay Banon) #5

Which threads are still running? Are those the ones listed on the top of
the gist? if so, they are not ES related.

On Wed, Jun 13, 2012 at 7:53 AM, Eugene Strokin eugene@strokin.info wrote:

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code here:
https://gist.github.com/2922102
I just @Autowire EsClientProvider and everything works fine, except when
application stops, I still have threads running and it hangs, and I need to
kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application
exits, but it doesn't change anything.

Thank you,
Eugene S.


(Eugene Strokin) #6

Sorry, I should've included more details about the threads.
I've updated the Gist:


The top one are the threads which are still running after application exits.
Thank you
Eugene

On Thursday, June 14, 2012 5:46:57 PM UTC-4, kimchy wrote:

Which threads are still running? Are those the ones listed on the top of
the gist? if so, they are not ES related.

On Wed, Jun 13, 2012 at 7:53 AM, Eugene Strokin wrote:

Hello,
I'm using Spring Bean to initialize ES TransportClient: see the code
here: https://gist.github.com/2922102
I just @Autowire EsClientProvider and everything works fine, except when
application stops, I still have threads running and it hangs, and I need to
kill the process to stop it.
Is anything could be done about this?
I've also tried explicitly call getClient().stop() before application
exits, but it doesn't change anything.

Thank you,
Eugene S.


(system) #7