[Bigdata-developers] FW: #53 Enhance build.xml to compile & package test source & allow one to run the junit tests from the command line or a script

[Bryan T. <br...@sy...>]

Brian, 

Following your excellent example, I have forwarded this on to the list.

I will see if I can adapt your LookupStarter to handle startup/shutdown of jini for the new ant tasks for managing a bigdata federation running on a single server.

Bryan
________________________________________
From: Brian Murphy [bri...@no...]
Sent: Wednesday, March 03, 2010 7:01 PM
To: Bryan Thompson
Cc: Gossard Sean (Nokia-S/Boston); Levine Brian (Nokia-S/Boston); Wharton Andrew (Nokia-S/Boston); Mcdonough Ryan (Nokia-S/Boston); Mike Personick; Martyn Cutcher; Morrison Bradley (Nokia-S/Boston); Additon Chris (Nokia-S/Boston)
Subject: Re: #53         Enhance build.xml to compile & package test source & allow one to run the junit tests from the command line or a script

Hi Bryan,

I've copied everyone else on this message because may be of
general interest to anyone on the list who might end up working
with Jini.

Brian

ext Bryan Thompson wrote:
> Brian,
>
> If I follow the pattern in your modified configuration for the test suites, which looks like this:
>
>     static private groups = new String[]{bigdata.fedname};
>     static private locators = new LookupLocator[] {};
>
> within the context of the src/resources/config/standalone/bigdataStandalone.config file then the ServicesManagerServer is never assign a ServiceID and things never get moving.
>
> However, if I setup the groups/locators as follows, then it works.
>
>     static private groups = LookupDiscovery.ALL_GROUPS;
>     static private locators = new LookupLocator[] {};
>
> Is the issue that the LUS needs to be started for the same value of "groups" that is specified in the configuration file?
Yes.

One thing to keep in mind though is that the lookup
service has two group-related config items, whereas all
other services have only one. Whereas Jini services
that are not a lookup service are told what group(s)
to find and join, the lookup service can be told not
only what group(s) to find and join, but more importantly,
what "member group(s) it is to belong to.

Because the lookup service is a Jini service itself, it
can be configured to find and register with (join) other
lookup services on the network; which is configured
similarly to how the other services are configured.
But the item that must be configured when starting a
lookup service that will cause other services to find
and join that lookup service is the "member group(s)".

As an example, if you look at the config file I committed
recently -- <baseDir>/src/resources/config/jini/serviceStarterAll.config --
you'll see the following:

    private static reggieArgs0 =
        "com.sun.jini.reggie.initialLookupGroups=new
String[]${groupsToJoin}";
    private static reggieArgs1 =
        "com.sun.jini.reggie.initialLookupLocators=new
LookupLocator[]${locsToJoin}";
    private static reggieArgs2 =
        "com.sun.jini.reggie.initialMemberGroups=new
String[]${memberGroups}";

The 2 items above that are being used to configure the reggie
implementation of the lookup service, tell that lookup service
what other lookup services it should find and join. This then,
is a way that lookup services can be chained.

The third item tells the lookup service the group(s) it should
announce itself as being a member of. That is, the value(s) of
that item is what other services will look for to join.

Thus, if a lookup service is started with group value(s) identical
to the group value(s) used to start the other services in the system,
but the set of "member" group(s) configured for that lookup service
does not contain at least one of the group names in the group set,
then the lookup service will not be discovered by those other
services. That is, there's no harm in setting the group(s) for the
lookup service, but it's the member group(s) that must be set
for the lookup service to be discovered.

The reason it works for what you used above -- that is --

  static private groups = LookupDiscovery.ALL_GROUPS;

is because the way ALL_GROUPS is specified is that it will
discover any lookup service, regardless of its group membership.
Note that even if the lookup service is started with a group
membership value of NO_GROUPS, I believe ALL_GROUPS
will still discover it.

As a side note, we always regretted providing ALL_GROUPS
because although it resulted in an initial success, it almost
always caused people problems in the long run; because they
ultimately want to isolate their federations from other federations.
So if your federation is the only federation on the network, then
ALL_GROUPS will work. But if there's another Jini federation
on the network -- for example, one that Chris starts -- then you
may have a lot of undesirable cross talk.

One other note. For those on the list who are not as familiar with
the Jini config files as Bryan is, the tokens ${groupsToJoin},
${locsToJoin}, and ${memberGroups} in the config items above
take advantage of Java's automatic system property substitution
mechanism. Rather than having to manually modify each config
file when you want to set groups and/or member groups, the
goal is to provide a mechanism where those values are set in
a single place -- for example, Bigdata's current build.properties --
and then have those values automatically propagated down to
the various config files so they don't have to be touched by
the deployer.

Another possibility we probably need to consider, is to exploit the
currently existing com.bigdata.jini.util.ConfigMath utility class to
achieve similar effects as above; rather than setting system properties.
This is something I was planning to investigate at some point.

Brian M