[jboss-jira] [JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations

[Nick Sawadsky (Jira)]

     [ https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Sawadsky updated JGRP-2320:
--------------------------------
    Description: 
Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified.

1. After the initial call to {{readAll()}}, there are a number of corrective steps that are taken if the address of the local node was not returned from {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the responses returned by readAll() are filtered based on the {{members}} parameter. To avoid unnecessary writes to the file (which may be in a cloud store), it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null.

2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. 

  was:
Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified.

1. After the initial call to {{readAll()}}, there are a number of steps taken that apply only if the address of the local node was not returned from {{readAll()}}. However, in the case where {{findMembers}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it would not be expected that the address of the local node is returned, since the responses returned by readAll() are filtered based on the {{members}} parameter. To avoid unnecessary writes to the file (which may be in a cloud store), it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null.

2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. 



> FILE_PING.findMembers() optimizations
> -------------------------------------
>
>                 Key: JGRP-2320
>                 URL: https://issues.jboss.org/browse/JGRP-2320
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.6.16, 4.0.15
>            Reporter: Nick Sawadsky
>            Assignee: Bela Ban
>            Priority: Minor
>
> Following on from JGRP-2288, a couple of possible optimizations/improvements to {{FILE_PING.findMembers()}} were identified.
> 1. After the initial call to {{readAll()}}, there are a number of corrective steps that are taken if the address of the local node was not returned from {{readAll()}}. However, in the case where {{findMembers()}} is invoked by {{TP.fetchResponsesFromDiscoveryProtocol()}}, it is normal if the local node address is not returned, since the responses returned by readAll() are filtered based on the {{members}} parameter. To avoid unnecessary writes to the file (which may be in a cloud store), it would be good to add some checks based on whether {{members}} is null or not. For example, the calls to {{write()}} and {{writeAll()}} should probably not occur unless {{members}} is null.
> 2. In the call to {{sendDiscoveryResponse()}}, the last parameter is always {{false}}. However, it seems possible for a coordinator to get to this point in some edge cases. Though I haven't been able to identify any clear bugs that this would lead to, it might be better to pass {{is_coord}} as the last parameter. 



--
This message was sent by Atlassian Jira
(v7.12.1#712002)