Hi Kanak,
I do agree that instantiating my own GenericHelixController is not
required. However, I will need to instantiate my own controller in its
place if I would like custom controller behavior and then this issue
could lead to strange behavior.
Vinayak
On 1/26/14, 1:36 PM, Kanak Biscuitwala wrote:
Hi Vinayak,
Looking at the code, here are a couple notes:
1. Instantiating your own GenericHelixController is unnecessary as the
Helix manager already does this.
2. Even considering #1, you're right: there are still repeat callbacks.
Here are the tracebacks I generated: https://gist.github.com/kanakb/8639730
The sequence is:
1. ZKHelixManager#handleNewSession() calls handleNewSessionAsController()
1. handleNewSessionAsController adds a controller callback for leader
election
2. CallbackHandler calls init on that controller callback
3. The controller callback adds all other callbacks, resulting in init
being called for each
4. ZKHelixManager#handleNewSession calls initHandlers()
5. initHandlers() iterates over all currently registered callbacks and
calls init() on them
6. CallbackHandler knows it's already received an init, so it simply
returns without doing anything on those callbacks
So yes, we do have repeat callback initializations for the controller
and it should be possible to avoid the double inits. These are, however,
harmless and inexpensive.
Kanak
> Date: Sun, 26 Jan 2014 12:13:16 -0800
> From: [email protected]
> To: [email protected]
> Subject: Duplicate INIT in Controller
>
> Hi,
>
> I am observing duplicate handlers being added to the controller and this
> is leading to INIT being called multiple times on the same handlers.
>
> Here is my code to start the controler, which looks fairly standard:
>
> @Override
> protected void doStart() throws SystemException {
> hManager = HelixManagerFactory.getZKHelixManager(clusterName,
> UUID.randomUUID().toString(),
> InstanceType.CONTROLLER, zkAddr);
> try {
> hManager.connect();
> } catch (Exception e) {
> throw new SystemException(e);
> }
> GenericHelixController controller = new GenericHelixController();
> HelixControllerMain.addListenersToController(hManager, controller);
> }
>
>
>
> Here are the log messages due to duplicate calls:
>
> 2014-01-26 12:11:16,721 WARN [CallbackHandler] Skip processing
> callbacks for listener:
> org.apache.helix.messaging.handling.HelixTaskExecutor@7f3076b2, path:
> /e78dead7-0c2f-4c5f-af7e-f25e8c170db1/CONTROLLER/MESSAGES, expected
> types: [CALLBACK, FINALIZE] but was INIT
> 2014-01-26 12:11:16,721 WARN [CallbackHandler] Skip processing
> callbacks for listener:
> org.apache.helix.controller.GenericHelixController@4db4bfda, path:
> /e78dead7-0c2f-4c5f-af7e-f25e8c170db1/CONFIGS/PARTICIPANT, expected
> types: [CALLBACK, FINALIZE] but was INIT
> 2014-01-26 12:11:16,721 WARN [CallbackHandler] Skip processing
> callbacks for listener:
> org.apache.helix.controller.GenericHelixController@4db4bfda, path:
> /e78dead7-0c2f-4c5f-af7e-f25e8c170db1/LIVEINSTANCES, expected types:
> [CALLBACK, FINALIZE] but was INIT
> 2014-01-26 12:11:16,721 WARN [CallbackHandler] Skip processing
> callbacks for listener:
> org.apache.helix.controller.GenericHelixController@4db4bfda, path:
> /e78dead7-0c2f-4c5f-af7e-f25e8c170db1/IDEALSTATES, expected types:
> [CALLBACK, FINALIZE] but was INIT
> 2014-01-26 12:11:16,721 WARN [CallbackHandler] Skip processing
> callbacks for listener:
> org.apache.helix.controller.GenericHelixController@4db4bfda, path:
> /e78dead7-0c2f-4c5f-af7e-f25e8c170db1/CONTROLLER, expected types:
> [CALLBACK, FINALIZE] but was INIT
>
>
> Thanks,
> Vinayak
