users@shoal.java.net

Re: [Shoal-Users] Group Membership Protocol

From: Mohamed Abdelaziz <Mohamed.Abdelaziz_at_Sun.COM>
Date: Sun, 07 Oct 2007 11:01:06 -0700

Brian McCallister wrote:
>
> On Oct 6, 2007, at 11:08 PM, Shreedhar Ganapathy wrote:
>
>> Hi Brian
>> With Shoal, a set of processes(JVMs) can each have Shoal libraries
>> loaded in-process so that components within each process can call
>> Shoal apis with individual member names and a common group name to
>> communicate with cluster members.
>> The Shoal GMS (Group Management Service) core implements
>> infrastructure code to support client api calls and a Service
>> Provider layer allows for inclusion of Group Communication Systems
>> such as Jxta to be used for Group Member Protocols and
>> Communication. Shoal's default service provider implementation has
>> a set of classes providing group communication protocols over Jxta
>> platform.
>
> Okay, so it is just an API over JXTA? Will go pester JXTA folks then
> :-) I am much more interested in getting a feel for the operational
> characteristics than I am the API. An API is an API, assuming it isn't
> as bad as java.util.Calendar, all is good. What it does at the network
> layer, what kinds of topologies it can handle, what liveness
> characteristics are expected, and how easy/hard it would be to support
> non-Java participants are my main concerns.


As you may already know JXTA is not limited to ip or a specific
programming or operating platform. There are several bindings of the
JXTA protocols, Java and C being prominent, I also know of a ruby
binding, and I have done a sub-set of the protocol in assembly for
bare-metal system discovery. To support a heterogeneous, one would have
to port the shoal's protocols (advertisement, ID format, master node,
and health monitor protocols).

>
>> In our tests with Shoal and a lightweight client layer, we have
>> scaled upto 32 nodes. With GlassFish v2 Application Server, we have
>> scaled to 8 nodes in a cluster. Effectively, scaling would vary
>> depending on several factors such as available heap space, load
>> characteristics of the application that consumes Shoal, and OS type
>> (32 bit v/s 64 bit), etc.
>
> So my guess is that a cluster of 1000, 10k, or 100k hosts is right out
> the window?


Not really, currently the health monitor as it is coded supports the
figures quoted by Shreedhar, that does not preclude improving it to
distribute the monitoring functions into islands instead of the full
scope of the cluster.

You got me curious, what kind of clusters are you thinking about?



>
>>
>> For using Shoal, do take a look at this introductory user guide blog
>> entry here : http://blogs.sun.com/shreedhar/entry/shoal_clustering_101
>
> I've gone through the guide and preso -- basically everything I can
> find short of looking through the code -- which is the next step if I
> want to continue to consider shoal, I guess.


We are also preparing a white paper for public consumption which shed a
little more details about cluster configuration and formation, which
we'll make available under shoal as soon as it is ready.


Cheers,
Mohamed