ServiceDiscoveryManager Tests

Spec Tests


Test Name & Motivation

Description

Category

Specification Requirements

org.apache.river.qa.spec.

servicediscovery.

DefaultDiscoverPublic


With respect to the lookup discovery processing performed by the ServiceDiscoveryManager utility class, verifies that the ServiceDiscoveryManager operates as specified. That is, this test verifies the following statement from the specification:


“If the value of the DiscoveryManagement argument is null, then an instance of the net.jini.discovery.

LookupDiscoveryManager utility class will be constructed to discover only those lookup services that are members of the public group.”

  1. Start no lookup services

  2. Create an instance of ServiceDiscoveryManager, inputting null for both the DiscoveryManagement parameter and the LeaseRenewalManager parameter

  3. Invoke the getDiscoveryManager method on the service discovery manager created in step 2

  4. Verify that the object retrieved in step 3 is and instance of LookupDiscoveryManager

  5. Invoke the getGroups method on the lookup discovery manager retrieved in step 3

  6. Verify the set of groups retrieved in step 5 contain only the public group

A1,M1

SD.4.1.1

org.apache.river.qa.spec.

servicediscovery.cache.

AddListenerNPE


Verifies that the addListener method of the lookup cache employed by the ServiceDiscoveryManager utility class operates as specified. That is, this test verifies the following statement from the specification:


“If null is input as the listener parameter of the addListener method of the LookupCache interface, a NullPointerException is thrown.”

  1. Start no lookup services

  2. Create an instance of ServiceDiscoveryManager, inputting an instance of DiscoveryManagement that discovers no groups and no locators, and inputting null to the LeaseRenewalManager parameter

  3. Invoke the createLookupCache method on the service discovery manager created in step 2

  4. Invoke the addListener method on the lookup cache created in step 2, inputting a non-null instance of ServiceDiscoveryListener so as to verify that a NullPointerException is not always thrown on any arbitrary invocation of the addListener method

  5. Invoke the addListener method on the lookup cache created in step 2, inputting null to the listener parameter

  6. Verify that a NullPointerException is thrown

A1,M1

SD.4.1.1

org.apache.river.qa.spec.

servicediscovery.cache.

CacheDiscard


Verifies that the discard method of the LookupCache interface operates as specified.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register 1 test service with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test service registered in step 2 based on service type only

  5. Invoke the createLookupCache method on the service discovery manager created in step 3; inputting the template created in step 4, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and null as the listener parameter

  6. With respect to the lookup method on the lookup cache created in step 5, invoke the version that returns a single instance of ServiceItem, inputting null as the filter parameter so that no second-stage filtering is applied by the lookup method

  7. Invoke the discard method on the lookup cache created in step 5, inputting the service reference returned by the lookup method in step 6

  8. Execute step 6 again and verify that the service has indeed been discarded as expected

A1,M1

SD.4.1.2

SD.5.5.1

org.apache.river.qa.spec.

servicediscovery.cache.

CacheLookup


With respect to the lookup method defined by the LookupCache interface, verifies that the version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the lookup cache applies no first-stage filtering to the results of the template matching

  • the lookup method of the lookup cache applies no second-stage filtering to the results of the template; that is, null is input as the filter parameter of the lookup method


ServiceItem lookup

(ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. Invoke the createLookupCache method on the service discovery manager created in step 3; inputting the template created in step 4, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and null as the listener parameter

  6. With respect to the lookup method on the lookup cache created in step 5, invoke the version that returns a single instance of ServiceItem, inputting null as the filter parameter so that no second-stage filtering is applied by the lookup method

  7. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.2

SD.5.5.1

org.apache.river.qa.spec.

servicediscovery.cache.

CacheLookupFilterFilter


With respect to the lookup method defined by the LookupCache interface, verifies that the version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the lookup cache applies first-stage filtering to the results of the template matching

  • the lookup method of the lookup cache applies second-stage filtering to the results of the template matching and the first-stage filtering


ServiceItem lookup

(ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. Invoke the createLookupCache method on the service discovery manager created in step 3; inputting the template created in step 4, the filter created in step 5 (so that first-stage filtering is applied by the lookup cache), and null as the listener parameter

  7. Create a second filter that will reject some – but not all – of the services that result when template matching and first-stage filtering are applied to the services registered in step 2

  8. With respect to the lookup method on the lookup cache created in step 6, invoke the version that returns a single instance of ServiceItem, inputting the filter created in step 7 so that second-stage filtering is applied by the lookup method

  9. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.2

SD.5.2.1

SD.5.5.1

org.apache.river.qa.spec.

servicediscovery.cache.

CacheLookupFilterNoFilter


With respect to the lookup method defined by the LookupCache interface, verifies that the version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the lookup cache applies first-stage filtering to the results of the template matching

  • the lookup method of the lookup cache applies no second-stage filtering to the results of the template matching and the first-stage filtering; that is, null is input as the filter parameter of the lookup method


ServiceItem lookup

(ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. Invoke the createLookupCache method on the service discovery manager created in step 3; inputting the template created in step 4, the filter created in step 5 (so that first-stage filtering is applied by the lookup cache), and null as the listener parameter

  7. With respect to the lookup method on the lookup cache created in step 6, invoke the version that returns a single instance of ServiceItem, inputting null as the filter parameter so that no second-stage filtering is applied by the lookup method

  8. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.2

SD.5.2.1

SD.5.5.1

org.apache.river.qa.spec.

servicediscovery.cache.

CacheLookupNoFilterFilter


With respect to the lookup method defined by the LookupCache interface, verifies that the version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the lookup cache applies no first-stage filtering to the results of the template matching

  • the lookup method of the lookup cache applies second-stage filtering to the results of the template


ServiceItem lookup

(ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. Invoke the createLookupCache method on the service discovery manager created in step 3; inputting the template created in step 4, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and null as the listener parameter

  6. Create a second filter that will reject some – but not all – of the services that result when template matching is applied to the services registered in step 2

  7. With respect to the lookup method on the lookup cache created in step 5, invoke the version that returns a single instance of ServiceItem, inputting the filter created in step 6 so that second-stage filtering is applied by the lookup method

  8. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.2

SD.5.2.1

SD.5.5.1

org.apache.river.qa.spec.

servicediscovery.event.

AddAttrServiceChanged


Verifies that the event mechanism defined by the LookupCache interface operates as specified with respect to the serviceAdded events when the set of attributes associated with a set of registered services is augmented (add attributes).

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are explicitly pre-set

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services that will be registered based on service type only

  4. With each of the lookup services started in step 1, register M test services along with an associated attribute, and verify that the registration was successful

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Verify that the lookup cache created in step 5 and its event mechanism operates as expected

  7. To each service registered in step 4, add a new attribute, and verify that the expected serviceAdded events are sent by the event mechanism of the lookup cache created in step 5

A1,M1

SD.4.1.2

SD.5.3.1

SD.5.4.1

org.apache.river.qa.spec.

servicediscovery.event.

ModifyAttrServiceChanged


Verifies that the event mechanism defined by the LookupCache interface operates as specified with respect to the serviceChanged events when the set of attributes associated with a set of registered services is modified.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are explicitly pre-set

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services that will be registered based on service type only

  4. With each of the lookup services started in step 1, register M test services along with an associated attribute, and verify that the registration was successful

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Verify that the lookup cache created in step 5 and its event mechanism operates as expected

  7. Modify the attributes associated with each service registered in step 4, and verify that the expected serviceChanged events are sent by the event mechanism of the lookup cache created in step 5

A1,M1

SD.4.1.2

SD.5.3.1

SD.5.4.1

org.apache.river.qa.spec.

servicediscovery.event.

SetAttrServiceChanged


Verifies that the event mechanism defined by the LookupCache interface operates as specified with respect to the serviceRemoved events when the set of attributes associated with a set of registered services is replaced.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are explicitly pre-set

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services that will be registered based on service type only

  4. With each of the lookup services started in step 1, register M test services along with an associated attribute, and verify that the registration was successful

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, null as the filter parameter (so that no first-stage filtering is applied by the lookup cache), and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Verify that the lookup cache created in step 5 and its event mechanism operates as expected

  7. Replace with a new set of attributes, the attributes associated with each service registered in step 4, and verify that the expected serviceRemoved events are sent by the event mechanism of the lookup cache created in step 5

A1,M1

SD.4.1.2

SD.5.3.1

SD.5.4.1

org.apache.river.qa.spec.

servicediscovery.lookup.

Lookup


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the non-blocking version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching


ServiceItem lookup

(ServiceItemTemplate tmpl,

ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the non-blocking version that returns a single instance of ServiceItem, inputting the template created in step 4, and inputting null as the filter parameter so that no filtering is applied by the lookup method

  6. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the non-blocking version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching


ServiceItem lookup

(ServiceItemTemplate tmpl,

ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. With respect to the lookup method on the service discovery manager created in step 3, invoke the non-blocking version that returns a single instance of ServiceItem, inputting the template created in step 4, and the filter created in step 5 so that filtering is applied by the lookup method

  7. Verify that the service item returned is the service item expected

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMax


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the non-blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching


ServiceItem lookup

(ServiceItemTemplate tmpl,

int maxMatches,

ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the non-blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, and inputting null as the filter parameter so that no filtering is applied by the lookup method

  6. Verify that the service items returned are the service items expected

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMaxFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the non-blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching


ServiceItem lookup

(ServiceItemTemplate tmpl,

int maxMatches,

ServiceItemFilter filter)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. With respect to the lookup method on the service discovery manager created in step 3, invoke the non-blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, and the filter created in step 5 so that filtering is applied by the lookup method

  7. Verify that the service items returned are the service items expected

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinEqualsMax


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching

  • the minimum number of desired services is equal to the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, inputting null as the filter parameter so that no filtering is applied by the lookup method, and inputting the same value for both the minMatches and maxMatches parameters

  6. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method blocks for the expected amount of time

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinEqualsMaxFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching

  • the minimum number of desired services is equal to the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, the filter created in step 5 so that filtering is applied by the lookup method, and inputting the same value for both the minMatches and maxMatches parameters

  7. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method blocks for the expected amount of time

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinLessMax


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching

  • the minimum number of desired services is less than the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, inputting null as the filter parameter so that no filtering is applied by the lookup method, and inputting values for the minMatches and maxMatches parameters in which minMatches is less than maxMatches

  6. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method blocks for the expected amount of time

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinLessMaxFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching

  • the minimum number of desired services is less than the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, the filter created in step 5 so that no filtering is applied by the lookup method, and inputting values for the minMatches and maxMatches parameters in which minMatches is less than maxMatches

  7. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method blocks for the expected amount of time

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinMaxNoBlock


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching

  • the number of services available for discovery is greater than the acceptable minimum number of services input to the lookup method


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)


If there are more services available to be discovered than the acceptable minimum number of services (minMatches), then no blocking should occur; rather, the lookup method should return immediately after discovering the acceptable number of services.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M (M >= 1) test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, inputting null as the filter parameter so that no filtering is applied by the lookup method, and inputting a value for the minMatches parameter that is less than or equal to the number of services registered in step 2, and a value for the maxMatches parameters that is greater than or equal to the value of minMatches

  6. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method returns immediately without blocking

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupMinMaxNoBlockFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns an array of instances of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching

  • the number of services available for discovery is greater than the acceptable minimum number of services input to the lookup method


ServiceItem lookup

(ServiceItemTemplate tmpl,

int minMatches,

int maxMatches,

ServiceItemFilter filter,

long waitDur)


If there are more services available to be discovered than the acceptable minimum number of services (minMatches), then no blocking should occur; rather, the lookup method should return immediately after discovering the acceptable number of services.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M (M >= 1) test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. During setup, create a filter that will reject some – but not all – of the services registered in step 2

  6. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns an array of instances of ServiceItem, inputting the template created in step 4, the filter created in step 5 so that no filtering is applied by the lookup method, and inputting a value for the minMatches parameter that is less than or equal to the number of services registered in step 2, and a value for the maxMatches parameters that is greater than or equal to the value of minMatches

  7. Verify that the service items returned are the service items expected, and that the blocking mechanism of the lookup method returns immediately without blocking

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupWait


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching

  • the minimum number of desired services is equal to the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test service that will be registered in step 6 based on service type only

  4. With respect to the lookup method on the service discovery manager created in step 2, invoke the blocking version that returns a single instance of ServiceItem, inputting the template created in step 3, and inputting null as the filter parameter so that no filtering is applied by the lookup method

  5. Verify that because no services are currently available to be discovered, the call to the lookup method blocks for the full amount of time requested through the waitDur parameter

  6. Register 1 test service with each of the lookup services created in step 1

  7. Again invoke the lookup method in the same way as in step 4, and verify that the service item returned is the service item expected, and that the blocking mechanism of the lookup method blocks until the registration of the test service from step 6 completes successfully

A1,M1

SD.4.1.1

SD.4.1.3

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupWaitFilter


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies filtering to the results of the template matching

  • the minimum number of desired services is equal to the maximum number of desired services


ServiceItem lookup

(ServiceItemTemplate tmpl,

ServiceItemFilter filter,

long waitDur)

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services that will be registered in steps 7 and 10 based on service type only

  4. During setup, create a filter that will reject some – but not all – of the services that will be registered in steps 7 and 10

  5. With respect to the lookup method on the service discovery manager created in step 2, invoke the blocking version that returns a single instance of ServiceItem, inputting the template created in step 4, and inputting the filter created in step 3 so that filtering is applied by the lookup method

  6. Verify that because no services are currently available to be discovered, the call to the lookup method blocks for the full amount of time requested through the waitDur parameter

  7. Register 3 test services and 1 associated attribute with each of the lookup services created in step 1

  8. Create a template that will match the test services registered in step 7 based on both the service type and each service’s associated attribute

  9. Again invoke the lookup method in the same way as in step 5, and verify that the service item returned is the service item expected, and that the blocking mechanism of the lookup method blocks until the registrations of the test services from step 6 complete successfully

  10. With each lookup service started in step 1, register 4 more test services, each with 1 associated attribute

  11. Create a template that will match the test services registered in step 10 based on both the service type and each service’s associated attribute

  12. Again invoke the lookup method in the same way as in steps 5 and 9, and verify that because the filter rejects the services that would normally be discovered if the filter were not applied, the call to the lookup method blocks for the full amount of time requested through the waitDur parameter

A1,M1

SD.4.1.1

SD.4.1.3

SD.5.2.1

org.apache.river.qa.spec.

servicediscovery.lookup.

LookupWaitNoBlock


With respect to the lookup method defined by the ServiceDiscoveryManager utility class, verifies that the blocking version that returns a single instance of ServiceItem operates as specified when invoked under the following conditions:

  • template matching performed by the service discovery manager is based on service type only

  • the service discovery manager applies no filtering to the results of the template matching

  • at least 1 matching service is already available for discovery when the lookup method is called


ServiceItem lookup

(ServiceItemTemplate tmpl,

ServiceItemFilter filter,

long waitDur)


If at least 1 matching service is already available to be discovered when the lookup method is called (that is, the lookup method does not have to wait for the desired service to be registered), then the lookup method will not block. In that case, the lookup method should return immediately after discovering the desired service.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, register M test services with some subset of the lookup services created in step 1

  3. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  4. During setup, create a template that will match the test services registered in step 2 based on service type only

  5. With respect to the lookup method on the service discovery manager created in step 3, invoke the blocking version that returns a single instance of ServiceItem, inputting the template created in step 4, and inputting null as the filter parameter so that no filtering is applied by the lookup method

  6. Verify that the service item returned is the service item expected, and that the blocking mechanism of the lookup method returns immediately without blocking

A1,M1

SD.4.1.1

SD.4.1.3


Impl Tests


Test Name & Motivation

Description

Category

Specification Requirements

org.apache.river.qa.impl.

servicediscovert.

TerminateSemantics


Verifies that – except for the terminate method itself – if any of the public methods of the current implementation of the ServiceDiscoveryManager utility class are invoked after the service discovery manager has been terminated, an IllegalStateException results. Also verifies that any invocation of the terminate method made after the initial invocation of terminate will result in no action being taken, and no exception being thrown.

  1. Start no lookup services

  2. Create an instance of ServiceDiscoveryManager, using the default parameters

  3. Invoke the terminate method on the service discovery manager created in step 1

  4. Invoke each public method (other than the terminate method itself) on the service discovery manager created in step 1, and verify that an IllegalStateException results on each invocation

  5. Invoke the terminate method on the service discovery manager created in step 1, and verify that no action is taken and no exception results

A1,M4

SD.3

SD.4.1.6

org.apache.river.qa.impl.

servicediscovert.cache.

CacheTerminateSemantics


Verifies that – except for the terminate method itself – if any of the public methods of the current implementation of the LookupCache interface (returned by the createLookupCache method of the ServiceDiscoveryManager utility class) are invoked after the lookup cache has been terminated, an IllegalStateException results. Also verifies that any invocation of the terminate method made after the initial invocation of terminate will result in no action being taken, and no exception being thrown.

  1. Start no lookup services

  2. Create an instance of ServiceDiscoveryManager, using the default parameters

  3. Invoke the createLookupCache method on the service discovery manager created in step 1

  4. Invoke the terminate method on the lookup cache created in step 2

  5. Invoke each public method (other than the terminate method itself) on the lookup cache created in step 2, and verify that an IllegalStateException results on each invocation

  6. Invoke the terminate method on the lookup cache created in step 2, and verify that no action is taken and no exception results

A1,M4

SD.5.5

SD.5.5.1

org.apache.river.qa.impl.

servicediscovery.event.

DiscardDownReDiscover


Verifies that the ServiceDiscoveryManager utility class handles the discard problem in the manner described in the specification. To do so, this test simulates the situation where an entity discards from a lookup cache, a service that actually goes down. This test then verifies that the service discovery manager identifies the situation and eventually commits the service discard that occurred previously. This test then verifies that when the down service comes back on line and re-registers with each lookup service, the service is re-discovered.


The discard problem occurs when an entity discards a service from a lookup cache (because the service is unavailable to the entity), but the entity is not really down (the service can still communicate with the lookup services with which it is registered). When this situation occurs, unless the service discovery manager takes steps equivalent to those described in section SD.5.5.1 of the specification, the service may never be re-discovered (because the service – since it’s not actually down – continues to renew its leases with the lookup services, so none of those lookup services will ever re-discover the service).

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Invoke the lookup method on the lookup cache created in step 5 and use the results to verify that the lookup and its event mechanism operate as expected

  7. Discard from the lookup cache, the services returned in step 6 to simulate service that appears down to the entity

  8. Verify that a serviceRemoved event occurs as a result of the service discard in step 7

  9. Stop renewing the lease each registered service holds with each lookup service (to simulate services that are actually down)

  10. Verify that the previously discarded service is not re-discovered

  11. Re-register each test service with each lookup service, and verify that each service is re-discovered

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

SD.5.5.1

org.apache.river.qa.impl.

servicediscovery.event.

DiscardServiceDown


Verifies that the ServiceDiscoveryManager utility class handles the discard problem in the manner described in the specification. To do so, this test simulates the situation where an entity discards from a lookup cache, a service that actually goes down. This test then verifies that the service discovery manager identifies the situation and eventually commits the service discard that occurred previously.


The discard problem occurs when an entity discards a service from a lookup cache (because the service is unavailable to the entity), but the entity is not really down (the service can still communicate with the lookup services with which it is registered). When this situation occurs, unless the service discovery manager takes steps equivalent to those described in section SD.5.5.1 of the specification, the service may never be re-discovered (because the service – since it’s not actually down – continues to renew its leases with the lookup services, so none of those lookup services will ever re-discover the service).

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Invoke the lookup method on the lookup cache created in step 5 and use the results to verify that the lookup and its event mechanism operate as expected

  7. Discard from the lookup cache, the services returned in step 6 to simulate services that appears down to the entity

  8. Verify that a serviceRemoved event occurs as a result of the service discard in step 7

  9. Stop renewing the lease each registered service holds with each lookup service (to simulate services that are actually down)

  10. Verify that the previously discarded service is not re-discovered

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

SD.5.5.1

org.apache.river.qa.impl.

servicediscovery.event.

DiscardServiceUp


Verifies that the ServiceDiscoveryManager utility class handles the discard problem in the manner described in the specification. To do so, this test simulates the situation where an entity discards from a lookup cache, a service that never actually goes down. This test then verifies that the service discovery manager identifies the situation and re-discovers the previously discarded service.


The discard problem occurs when an entity discards a service from a lookup cache (because the service is unavailable to the entity), but the entity is not really down (the service can still communicate with the lookup services with which it is registered). When this situation occurs, unless the service discovery manager takes steps equivalent to those described in section SD.5.5.1 of the specification, the service may never be re-discovered (because the service – since it’s not actually down – continues to renew its leases with the lookup services, so none of those lookup services will ever re-discover the service).

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Invoke the lookup method on the lookup cache created in step 5 and use the results to verify that the lookup and its event mechanism operate as expected

  7. Discard from the lookup cache, the services returned in step 6 to simulate services that appears down to the entity

  8. Verify that a serviceRemoved event occurs as a result of the service discard in step 7

  9. Verify that the previously discarded – but actually up – service is eventually re-discovered

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

SD.5.5.1

org.apache.river.qa.impl.

servicediscovery.event.

ReRegisterBadEquals


With respect to the use of a lookup cache to perform service discovery, this test verifies that when the services to be discovered are implemented with a poorly defined or non-existent (bad) equals method, the event mechanism of the lookup cache will operate in a predictable fashion, sending a number of serviceAdded and serviceRemoved events.


With respect to services defined with a bad equals method, the lookup cache will always view different instances of such services as being different. Based on this fact, the number of serviceAdded and serviceRemoved events can be computed from the number of services and the number of lookup services with which each service has registered.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services – each containing a poorly defined or non-existent equals method – with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. After the original services have been discovered and all expected notifications have arrived, register a new version of each of the previously registered services.

  7. Verify that the expected serviceAdded and serviceRemoved events occur

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

org.apache.river.qa.impl.

servicediscovery.event.

ReRegisterGoodEquals


With respect to the use of a lookup cache to perform service discovery, this test verifies that when the services to be discovered are implemented with a well defined (good) equals method, the event mechanism of the lookup cache will operate in a predictable fashion, sending a number of serviceAdded and serviceRemoved events.


With respect to services defined with a good equals method, the lookup cache will always view different instances of such a service as being the same service since different instances of the service will have the same service ID. Based on this fact, the number of serviceAdded and serviceRemoved events can be computed from the number of services and the number of lookup services with which each service has registered.

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services – each containing a well defined equals method – with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. After the original services have been discovered and all expected notifications have arrived, register a new version of each of the previously registered services. That is, each new version should be associated with a new service value so that the equals method returns false, but each new version should have the same service ID as its original counterpart so that the cache will interpret the different versions as the same service.

  7. Verify that the expected serviceAdded and serviceRemoved events occur

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

org.apache.river.qa.impl.

servicediscovery.event.

ServiceDiscardCacheTerminate


Verifies that the ServiceDiscoveryManager utility class handles the discard problem in the manner described in the specification by verifying that the tasks involved in the service discard process are terminated correctly when the lookup cache itself is terminated.


The discard problem occurs when an entity discards a service from a lookup cache (because the service is unavailable to the entity), but the entity is not really down (the service can still communicate with the lookup services with which it is registered). When this situation occurs, unless the service discovery manager takes steps equivalent to those described in section SD.5.5.1 of the specification, the service may never be re-discovered (because the service – since it’s not actually down – continues to renew its leases with the lookup services, so none of those lookup services will ever re-discover the service).

  1. During setup, start N lookup services whose member groups are finite (not NO_GROUPS) and unique (not public) relative to the member groups of all other lookup services running within the same multicast radius of the lookup; and whose locator ports are randomly selected

  2. During setup, create an instance of ServiceDiscoveryManager that discovers the lookup services started in step 1, and which uses the default lease renewal manager to manage any leases on registrations with the event mechanism of the lookup services

  3. During setup, create a template that will match the test services to be registered based on service type only

  4. Register M test services with some subset of the lookup services created in step 1

  5. Invoke the createLookupCache method on the service discovery manager created in step 2; inputting the template created in step 3, and a non-null instance of ServiceDiscoveryListener to register with the event mechanism of the lookup cache returned by the call to createLookupCache

  6. Invoke the lookup method on the lookup cache created in step 5 and use the results to verify that the lookup and its event mechanism operate as expected

  7. Discard from the lookup cache, the services returned in step 6 to cause creation of tasks that handle the discard problem

  8. Invoke the terminate method on the lookup cache created in step 5

  9. Stop renewing the lease each registered service holds with each lookup service to cause the generation of service events

  10. Verify that the expected service events are received

A1,M4

SD.4.1.2

SD.5.3.1

SD.5.4.1

SD.5.5.1