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 > >
