Summary: The section explains How to Configure and use Unicast Discovery.
OverviewThere are many cases when you need to use a unicast-based services discovery. For example if you want to to use unicast with multicast (using Jini Groups), which is the default, or when you do not have multicast enabled, or you prefer not to use multicast. In such cases, the Jini lookup discovery enables the user to discover services (spaces, GSC, GSM, processing units etc.) using unicast protocol.
Configuring the lookup locators propertyServices will use the locators property to locate the Jini Lookup Service to lookup other services registered on it. The locators property is configured using the LOOKUPLOCATORS environment variable or the -Dcom.gs.jini_lus.locators system property. By default it is left blank. It accepts a comma separated list of host:port. This list should include the hosts (and ports) where the Jini Lookup Service (or GSM) is running. The default port is 4164. For example, considering the GSM(+LUS) is running on linux-lab1:4164 and linux-lab2:4164 machines: -Dcom.gs.jini_lus.locators=linux-lab1:4164,linux-lab2:4164 This will influence the LOOKUPLOCATORS environment variable in setenv script, which you may also modify directly. Locating services using locatorsOnce the services are started with the locators settings, then any client should be able to find a service, using unicast discovery. To lookup a Space service using the unicast protocol, add the locators SpaceURL attribute to the space URL string. For both unicast AND multicast discovery, use: jini://*/./mySpace?locators=linux-lab1:4164,linux-lab2:4164&groups=gigaspaces-7.0.0-XAPPremium-ga
Configuring Jini Lookup Service Unicast PortTo change the lookup service port when using the Service Grid, you can use the com.sun.jini.reggie.initialUnicastDiscoveryPort system property. The default value is the one assigned to the com.gs.multicast.discoveryPort system property, that is 4164 with XAP 7.x.
Configuring lookup discovery intervalsWhen a lookup service fails and is brought back online, a client (such as a GSC, space or a client with a space proxy) needs to re-discover and federate again. In order to make that happen, Jini unicast discovery must retry connections to the remote lookup service. The default unicast retry protocol provides a graduating approach, increasing the amount of time to wait before the next discovery attempts are made - upon each invocation, eventually reaching a maximum time interval over which discovery is re-tried. In this way, the network is not flooded with unicast discovery requests referencing a lookup service that may not be available for quite some time (if ever). The default time to wait between unicast retry attempts are: long[] sleepTime = {5 * 1000, 10 * 1000, 20 * 1000,
30 * 1000, 60 * 1000,
2 * 60 * 1000, 4 * 60 * 1000,
8 * 60 * 1000, 15 * 60 * 1000};
You'll max out at 15 minutes between retries. Thats a big window. To tune the unicast retry intervals, the com.gigaspaces.unicast.interval system property is used to control the behavior of this LookupLocatorDiscovery utility. A comma separated list of values defining the intervals to wait between subsequent retries. Values are declared in milliseconds. Example: -Dcom.gigaspaces.unicast.interval=5000 Will cause the LookupLocatorDiscovery utility to wait 5 seconds between retries -Dcom.gigaspaces.unicast.interval=5000,10000 Will cause the LookupLocatorDiscovery utility to first wait 5 seconds, then 10 seconds between retries. This declaration provides a graduating approach (similar in approach to the default settings). You will need to set this property to take affect for GSM and GSC startup. You should see a similar log message to "Set unicast interval to 5000". |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |