there's a patch up to do the deletion (best effort) when things get taken down...I plan to pull it in once we've got this 0.90 release out
> On 23 Dec 2015, at 20:21, Jon Maron <[email protected]> wrote: > >> >> On Dec 23, 2015, at 3:13 PM, Manoj Samel <[email protected]> wrote: >> >> Thanks Jon, >> >> I thought the ZK registry was to reflect the live information about the >> running application (i.e. I expected it to fail with no nodes found when >> app is not running) but that does not seems to be the intent. >> >> On the other hand, >> http://<slider-am-host>:1025/ws/v1/slider/publisher/slider/componentinstancedata >> <http://ip-10-222-0-38.us-west-2.compute.internal:1025/ws/v1/slider/publisher/slider/componentinstancedata> >> gives >> info only when app is running. Should the clients be quering this URL >> rather than ZK nodes to if they expect to get info only when app is running >> ? > > I would say that, in general, to get information about the live instances it > is best to leverage the URIs. They generally provide access to in-memory or > registry based information. > >> >> Thanks, >> >> Manoj >> >> On Wed, Dec 23, 2015 at 11:12 AM, Jon Maron <[email protected]> wrote: >> >>> >>>> On Dec 23, 2015, at 2:03 PM, Manoj Samel <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> Setup - slider version .80, secure hadoop cluster, registry enabled with >>>> security >>>> >>>> Noticed using *** zookeeper client (zkCli.sh) *** that when slider >>>> application is stopped, the registry entries in >>>> zookeeper /registry/users/xxx/services/org-apache-slider/abc/components >>> do >>>> not get deleted. However, they do get updated when application is started >>>> again and new container IDs get allocated. In this case, the >>>> components/containers_ do reflect new container IDs. Also noticed that ZK >>>> registry entries do get deleted if "destroy" applications is done. >>>> >>>> Is this expected behavior ? Shouldn't the ZK entries be deleted when >>>> application and its containers are not present after application is >>> stopped >>>> ? >>> >>> Not exactly. You could think of start/stop as thaw/freeze (their actual >>> previous incarnation). The idea is that a “stop” terminates the >>> application instance but maintains the configuration so that another >>> instance can be started based on the same configuration. You probably >>> could also think of the ZK config as the “class definition” and the actual >>> launched instance as the “Object”. >>> >>>> >>>> Thanks in advance, >>>> >>>> Manoj
