[jira] Created: (RIVER-112) DGM: spec needs more detail on IOException from add/setGroups

["Jim Hurley (JIRA)" <ji...@apache.org>]

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

                 Key: RIVER-112
                 URL: https://issues.apache.org/jira/browse/RIVER-112
             Project: River
          Issue Type: Bug
          Components: net_jini_discovery
    Affects Versions: jtsk_1.2
            Reporter: Jim Hurley
            Priority: Minor


Bugtraq ID [4411761|http://bugs.sun.com/bugdatabase/view_bug.do?bug_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.

Comments:
 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.