regarding service, I am looking for the api to instantiate a Member Role,
join the cluster, add listeners, register state transition handlers. In
0.6.x we used to do this via HelixManager. If you look at Quickstart.java
manager = HelixManagerFactory.getZKHelixManager(CLUSTER_NAME,
instanceName, MemberRole.PARTICIPANTZK_ADDRESS);
MasterSlaveStateModelFactory stateModelFactory = new
MasterSlaveStateModelFactory(instanceName);
StateMachineEngine stateMach = manager.getStateMachineEngine();
stateMach.registerStateModelFactory(STATE_MODEL_NAME.toString(),
stateModelFactory);
manager.connect();
I was trying to visualize the equivalent of this. something like
ParticipantService service = new MyService() // ParticipantService is an
abstract class probably
service.start();
service.registerStateTransitionHandler(StateModelName,
stateTransitionHandlerFactory);
service.getXX().addEventHandler(.....);
service.stop();
thanks,
Kishore G
On Wed, Apr 30, 2014 at 8:57 AM, Sandeep Nayak <[email protected]> wrote:
> I will start working on the following
>
> * Symmetric APIs
> * Start looking at HelixAdmin and figure what/how the commands will
> change. I lost sight of it along the way.
> * Put some thought into clarity in commands, could be through
> javadocs, clear APIs on builder-factory...maybe other things I am
> missing
>
> - I don't understand the need for service could you elaborate? I was
> going with the assumption that when we execute the command through the
> administrator we would have the members created and join the cluster
>
> - Event listeners will be a part of message/events which we need to
> look at once the model is as good as we want it to be.
>
> - The user only needs SPI in his class-path if he is writing custom
> providers as say replacement for zookeeper
>
> I can document how the sub-project dependencies are, maybe on a wiki
> page. But for the rest of the folks here is how it will be
>
> * api - has no dependency on anything
> * core - has dependency on API, if we keep zookeeper implementation in
> core we will have a dependency on SPI.
> * helix-zk - If we do this then core wont have dependency on spi, we
> will have helix-zk, helix-hazelcast etc which also depend on spi
> * spi - has no dependency on core, we should not put a dependency on API
>
> Thanks
>
> Sandeep
>
> On Wed, Apr 30, 2014 at 12:54 AM, kishore g <[email protected]> wrote:
> > Looking great. Feedback/comments
> >
> > -- HelixAdministratorClient methods are not symmetric. addXXX, removeXXX,
> > updateXXX
> > -- Its hard to know the subclasses of command, how to set the
> configuration
> > for a member, partition, resource, cluster. how to register a
> statemachine
> > -- we need service for each member type. ParticipantService,
> > ControllerService etc, how do these get created and join the cluster.
> > -- What about the event listeners. I guess that will be part of
> > message/events
> > -- so the user does not need spi package to write his code ?
> > -- I think i got the answer for this, but will be nice to know the
> > dependency tree between the packages and how will it be once we move have
> > specific implementations for zk, database, hazelcast/infinispan etc
> > -- I am worried about the commands, that it might lead to an explosion.
> we
> > should look at existing helixadmin class and see what would it mean to
> > support all those methods.
> >
> >
> > I will try to write a recipe using these api's and that will help me give
> > better feedback.
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 29, 2014 at 11:10 PM, Sandeep Nayak <[email protected]>
> wrote:
> >
> >> Hey guys,
> >>
> >> I finally got around incorporating the review feedback and all changes
> >> are checked in. Where should I look to next? I think there is more to
> >> do with the API but wanted to pause and ask what should I focus on
> >> next.
> >>
> >> Here are the open items on the top of the list
> >>
> >> * Rebalancer API
> >> * Message and/or Events
> >>
> >> Let me know what should be next and I will tackle it accordingly.
> >>
> >> Thanks,
> >>
> >> Sandeep
> >>
>
