[jboss-jira] [JBoss JIRA] (JGRP-2320) FILE_PING.findMembers() optimizations
[
https://issues.jboss.org/browse/JGRP-2320?page=com.atlassian.jira.plugin....
]
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()}}, some corrective steps are taken if the local
node address was not returned by {{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 {{readAll()}} responses are filtered
based on the {{members}} parameter.
To avoid unnecessary writes to the file or 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 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.
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()}}, some corrective steps are taken if the local
node address was not returned by {{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 {{readAll()}} responses are filtered
based on the {{members}} parameter.
To avoid unnecessary writes to the file or 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)