Uploaded image for project: 'River'
  1. River
  2. RIVER-112

DGM: spec needs more detail on IOException from add/setGroups


    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: jtsk_1.2
    • Fix Version/s: None
    • Component/s: net_jini_discovery
    • Labels:
    • Bugtraq ID:


      Bugtraq ID 4411761

      Although the specification of DiscoveryGroupManagement describes the
      conditions under which an IOException is thrown by either addGroups()
      or setGroups(), it does not specify the behavior (with respect to the
      state of the entity implementing DiscoveryGroupManagement) that should
      occur when such an exception does occur.

      For example, the specification could state that when add/setGroups()
      encounters an IOException, any further behavior of the current
      invocation is implementation-dependent. That is, it may or may not
      modify the set of groups to discover as requested, and may or may
      not allow for the discovery of those groups.

      Or it could state explicitly that in the face of an IOException,
      the entity will behave as if add/setGroups() was never called; that is,
      the requested group modifications will not be made, and attempts
      to discover the new groups will not be made.

      If option 2 as described in the Description section is chosen, then
      our current implementation must be changed.

      If option 1 is chosen, then we might consider modifying our current
      implementation to catch the IOException and not re-throw it since
      the Multicast announcements will still be received from the new
      groups (even though the IOException prevented Multicast requests
      from being sent), and discovery of the desired groups will still
      eventually occur. [If this is done, then the spec will need to be
      modified to allow this.]

      This requires a modification to the existing spec. It's unclear
      what the policy is regarding spec changes that cause the current
      documents to be inconsistent with the books. It is also unclear
      which for which release a change such as this would be appropriate;
      alewife (maintenance/feature realease implies no spec changes?)
      or davis.

      This needs more investigation.




            • Assignee:
              jhurley Jim Hurley
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: