Cannot shutdown webapp with embedded hornetq

[aruffie]

Hello all,

I have a web application with correctly deploy, interact, send, receive messages of its embedded hornetq server.

But when I try to stop my webapp in order to undeploy it (in continus integration phase), I get the logs attached

in hornetq.log (look in file attachment of this discussion). I think the problem is an blocked thread, but I don't

know how to determine et how to correct this leak. I think Tomcat try to clear referenced threads, but one in

embedded hornetq of webapp is keep active, therefore when I try to undeploy my webapp the hornetq-configuration.xml

file is locked under /mywebapp/WEB-INF/classes/META-INF/hornetq-configuration.xml

Any one have an idea ? How I can correct this problem ?

Thank & Best regards.

Adrien

[clebert.suconic]

Since you have it embedded, you have to call server.stop before you stop your application, otherwise HornetQ will have threads running.

You could add a shutdow hook maybe? just a simple server.stop() on the shutdown hook (look on the javadoc for more information)

[aruffie]

Yes I know the server must be stop, this is what I do in my LoaderServlet (its initialize and destroy my webapp).

I have attached this class, but I think it's a problem of locking the hornetq-configuration.xml file, because when

I try to delete my webapp directory under tomcat/webapps/ only this file is present while all others were deleted.

A configuration that was used to load the server, it must be unloaded?

I also try to kill threaddump but nothing, 2, 3 thread remains active ... (look threaddump.log)

Adrien

[yong_ouyang]

You don't need to use xml file to configurate your hornetq. You can try whether this helps.

[aruffie]

No sorry I need to use xml file, because our configuration is here.

[clebert.suconic]

These two Threads belong to the globalThreadPool created for the clients. You can configure the ServerLocator to not use a global Thread pool through the propery useGlobalPools = false, however these threads are daemon threads and they shouldn't block the shutdown of your server. It must be something else.

Look at the thread dump from the VM instead. That method you used is meant to be used within the application when crashes are about to happen.