You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@helix.apache.org by Sandeep Nayak <os...@gmail.com> on 2014/04/30 08:10:30 UTC

API Update: review feedback incorporated, checked in

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

Re: API Update: review feedback incorporated, checked in

Posted by kishore g <g....@gmail.com>.
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 <os...@gmail.com> 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 <g....@gmail.com> 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 <os...@gmail.com>
> 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
> >>
>

Re: API Update: review feedback incorporated, checked in

Posted by Sandeep Nayak <os...@gmail.com>.
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 <g....@gmail.com> 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 <os...@gmail.com> 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
>>

Re: API Update: review feedback incorporated, checked in

Posted by kishore g <g....@gmail.com>.
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 <os...@gmail.com> 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
>