Sumit, Haven't determined if the HA provider will do what I need yet but it isn't looking that way.
I am unable to figure out what in failoverRequest links back to the service registry lookupServiceUrl() could you point it out to me? Thanks, Kris From: Sumit Gupta <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, June 16, 2015 at 10:43 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: New service definitions with non-standard topology role hostnames. Hey Kris, The class WebHdfsHaDispatch and method failoverRequest has some code in there that causes the method lookupServiceUrl() to be called again. The HA Provider mainly manages the services that have HA capabilities using the HA configuration and the service registry's URL information. There are thoughts I have around enhancing the service registry to have some more the multiple url management capabilities, but for now hopefully the HA provider can do what you need. Are you looking to add a special dispatch and use the HA provider or add a provider as well for Solr? Sumit. On 6/16/15, 11:04 AM, "Kristopher Kane" <[email protected]<mailto:[email protected]>> wrote: Kevin, ServiceRegistryFunctionProcessorBase.lookupServiceUrl() and subclasses - Just to verify, these are added at Knox startup to register the end point URL with the role name. Is lookupServiceUrl() only called at startup and the HA Provider there is simply to provide a starting point URL for HA services? I was thinking to add the Solr provider there but want to ensure that these checks are not happening with each call. I don't believe they are as the WebHDFS HA provider is doing work elsewhere. Kris On Thu, May 28, 2015 at 10:21 PM, Kristopher Kane <[email protected]<mailto:[email protected]> wrote: Thanks for the detailed response Kevin. I will give it a shot tonight. NowŠ The outstanding question for me is the list is Zookeeper URLs. We may want to treat them like we do the NAMENODE and JOBTRACKER services today which are in the topology (and therefore in the service registry) but not really exposed. That was my intention. Thanks, Kris
