Hi Viktor
Viktor.Claesson_at_ibs.se wrote:
>
> Hi!
> Thanks for your answers!
>
> In my application there are a couple of servers as core members and a
> lot of clients as spectators. The shoal framework is only used to
> decide which member the clients should connect to, and this is group
> leader's task (weighted round robin).
Is this the task of a core member currently ? In other words, would one
of the core servers be both processing requests and proxying requests to
the other server?
> Making a spectator(client) group leader would in this case letting a
> client decide which member all the other clients should connect to and
> that doesn't feel right. Am I using the framework in a "bad" way?
With the approach to use the group leader to do the distribution task, I
don't see a problem with a client process that is termed as, say, the
Task Distributor or Load Balancer, doing the job of distributing tasks.
Potentially, a member can then be an executor of tasks and also be a
distributor of tasks depending on the combination of group leader and
core member roles. If a member is a group leader and a spectator then it
will solely be distributing tasks.
It makes this a more dynamic and interesting example of your group
member processes participating in the group such that regardless of the
spectator or core role, the group leader process, can potentially do
both the execution, and distribution of tasks.
I find that an interesting usage of Shoal. That's of course my view of
the world :)
Another approach is to not use the group leader as the determining
factor for this, but only pick the first core member to be the task
distributor. You can do that by calling
GroupHandle.getCurrentCoreMembers() and pick the first one.
As the views are identical on all members, the selection is expected to
be predictably the same in all processes.
> Date: Thu, 17 Apr 2008 10:55:46 -0700
> From: Shreedhar Ganapathy <Shreedhar.Ganapathy_at_Sun.COM>
> Content-type: multipart/alternative;
> boundary="Boundary_(ID_K7t9fXcMXPa5oHOLCJQX4Q)"
> Subject: [Shoal-Users] Unplanned shutdown of a spectator
>
>
> Hi Viktor
> Thanks for writing up these interesting questions. Hope my responses
> clarify things for you.
>
> Viktor.Claesson_at_ibs.se wrote:
> >
> > Hi!
> > I have some servers as core members in a group. With an administration
> > program I log on as a spectator. If this program makes an unplanned
> > shutdown, it will still be in the group and the core nodes will try to
> > send messages to the spectator node until the entire group has been
> > shutdown.
> If the spectator process leaves the group either abruptly or in a
> planned shutdown, a view change is surely disseminated to all members
> although a failure notification signal or planned shutdown signal is not
> sent out to the core member clients by design.
> > Is there any way to stop this?
> The role of spectator was specifically designed to not impact core
> members with its failure (unplanned shutdown). If the member is
> continuing to stay in the view after its failure after the failure
> verification timeouts have elapsed then that would be a bug.
> Could you confirm and then file a bug report?
>
> Also please let us know which version of Shoal you are using.
>
> > Do you assume that a spectator node always makes a planned shutdown?
> No not necessarily.
> >
> > Changing the admin program to become a core-member will of course
> > solve this, but then I will run into another problem, it can become
> > the group leader.
> Will the Spectator becoming the group leader be of concern ? Do please
> explain how it would affect your application as it will help us broaden
> our view.
>
> Nothing prevents a Spectator from becoming a group leader in Shoal as
> group leadership is a group management with by the service provider
> implementation. This does not necessarily have any bearing on the
> consuming application. There are, of course, Shoal users who have
> nmc``cnasked for APIs (which we have provided) that will give them
> programmatic access to knowing who the group leader is but it is not the
> intention to prevent Spectator's from becoming group leaders. When
> spectator's fail or shutdown normally, another node is selected
> deterministically to become the group leader.
>
> Semantically, the Spectator's failure is not notified to GMS clients,
> that's all. Internally, the Shoal service provider implementation does
> recognize each member's failure and does appropriate view handling.
>
> hth
> Shreedhar
> >
> > Thanks in advance!
> > Viktor
>
>
>