Saba On Thursday, December 19, 2013, Jordan Zimmerman wrote:
> Cxavazwasaassxxswaszsszs > > On Wednesday, December 18, 2013, Cameron McKenzie wrote: > >> Thanks Jordan, >> This is in a JBoss environment, but I'll try passing in my own executors >> and see how it goes. Currently, Curator is allocating them (as far as I >> know, I'm not providing any Executors), so it must be the way that JBoss >> handles undeploy / shutdown. >> cheers >> >> >> On Thu, Dec 19, 2013 at 6:56 AM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> I’ve personally used Curator with Tomcat and had no problems. Allocate >>> your own Executors and pass them to Curator or let Curator allocate them. >>> >>> -Jordan >>> >>> On Dec 17, 2013, at 4:21 PM, Cameron McKenzie <[email protected]> >>> wrote: >>> >>> > I've been using Curator in a standard Java environment, and haven't >>> had any issues with it, but have just started using the same code in an >>> appserver environment and have come across an issue. >>> > >>> > While, it's probably considered 'bad' to use Curator in this >>> environment because it uses its own thread management, it runs fine in the >>> vast majority of cases. The only time I have experience issues with it is >>> when trying to call close() on the CuratorFramework instance. Specifically, >>> calling close() when the app server is shutting down. >>> > >>> > The problem occurs because Curator uses an Executor to send the >>> 'shutting down' events to listeners, and the appserver has shut down all >>> its Executor services because it's shutting itself down. >>> > >>> > My work around is to catch any runtime execptions thrown by the >>> CuratorFramework close() method, and in this case grab the ZooKeeper >>> connection from Curator and closing this. It's a bit ugly though. >>> > >>> > Any suggestions (other than not using an appserver, or not using >>> Curator in this environment)? >>> > >>> > One fix would be to not use the Executor during shutdown to send the >>> events, and instead just do this in the thread doing the shutdown. I doubt >>> this would have great performance implications, given that you're unlikely >>> to have millions of listeners. >>> > >>> > Thoughts? >>> > cheers >>> > Cam >>> >>> >>
