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 :-)
Well I think I mention above that there is a service provider
implementation layer over Jxta to get Group Comm semantics. So its more
than an API over Jxta platform. The API comprises of a set of group
event notifications such as member joins, shutdowns, failure suspicions,
failure confirmations and a notifying a member when its selected for
performing recovery operations of resources in a failed member. That's a
value add that many Shoal users have found over directly using group
comm frameworks which either lack such facilities or merely send out new
group views with no information on the event accompanying it.
Additionally, it provides a Distributed State Cache implementation which
is currently a shared cache with transports being relied upon the
service provider namely Jxta.
The benefits that the service provider implementation provides is
articulated well in Mohamed's (Jxta Architect and tech leader) very
recent blog entry :
http://blogs.sun.com/hamada/entry/dynamic_scalable_clustering
> 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,
This is dependent on Jxta. The benefit Jxta provides here is
transparency of transports so that one can use TCP, UDP, etc easily
without changing protocol stacks i.e unicast (peer 2 peer) messages are
always using TCP/NIO and multicast messages are over UDP. There is an
http option which we have not yet taken advantage of.
> what kinds of topologies it can handle,
Can you expand on this? Shoal provides the ability to participate in a
cluster either as a core member or as a spectator. This helps where in
processes such as a LB or an administrative server can be spectators
with their failures not impacting the cluster in terms of remedial actions.
> what liveness characteristics are expected,
We ran longevity tests and stress tests on GlassFish v2 clusters 24x7
before release and it has performed well through these tests. Could you
share what you are looking for in terms of liveness?
> and how easy/hard it would be to support non-Java participants are my
> main concerns.
At the moment the API is oriented towards Java participants. Jxta is
capable of handling non-Java participants.
>
>> 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?
I am not saying that. It would be useless information for me to claim on
the lines above without real testing data. We have not had the equipment
or resources to go there. If you do, it would be help us greatly and for
the rest of Shoal users. So please let us know.
>
>>
>> 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.
Why not try it out? The information is available on the Shoal site wrt
javadocs, running the sample (slightly different from the one in the
blog), and design docs. Let us know of your requirements and we can
address them specifically.
>
> -Brian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>