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