You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Cameron McKenzie <mc...@gmail.com> on 2013/12/17 22:21:51 UTC
Curator in an appserver environment
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
Re: Curator in an appserver environment
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <
>> jordan@jordanzimmerman.com> 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 <mc...@gmail.com>
>>> 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
>>>
>>>
>>
Re: Curator in an appserver environment
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <
> jordan@jordanzimmerman.com <javascript:_e({}, 'cvml',
> 'jordan@jordanzimmerman.com');>> 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 <mckenzie.cam@gmail.com<javascript:_e({}, 'cvml', 'mckenzie.cam@gmail.com');>>
>> 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
>>
>>
>
Re: Curator in an appserver environment
Posted by Cameron McKenzie <mc...@gmail.com>.
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 <
jordan@jordanzimmerman.com> 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 <mc...@gmail.com>
> 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
>
>
Re: Curator in an appserver environment
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <mc...@gmail.com> 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