Re: [jgroups-dev] https://jira.jboss.org/browse/JGRP-1240

Mike Jensen <[email protected]>
Newsgroups gmane.comp.java.javagroups.devel
Message-ID <[email protected]>
Ah yes!  Well I found out what is going on.  So maybe you can give some 
clarification as to why it is doing what it is, I suspect it is me using 
JGroups incorrectly

Basically it all stems from the fact that I am now using FIND_ALL_MBRS 
instead of FIND_INITIAL_MBRS now for my node discovery.  I made this 
change because now I expect member discovery to run all the time.  We 
regularly make a call to get a list of members, and if we ever find a 
node via member discovery (currently using MPING) that we can not 
communicate to via the normal mesh structure, then we assume that this 
is a partition.  And we connect to them asking if they want to merge 
into us (there are more details here about the merge process, but i 
don't think they are relevant, so just recognize that this is a bit of a 
simplified description).  I made the change to FIND_ALL_MBRS as my 
understanding from looking at the code was that this was the appropriate 
method to detect possible partitions or orphaned nodes.

So the problem with using FIND_ALL_MBRS is this:
If you look on line 202 and 208 of Discovery.java you will notice 
something I think is interesting.  When we call findInitialMembers from 
the path that occurs with FIND_INITIAL_MBRS (so line 202), there is a 
false passed in for the value "return_views_only".  Alternatively with 
the FIND_ALL_MBRS code path (line 208 of Discovery.java), we pass in a 
true for "return_views_only".

If I change line 208 to also pass in false like the FIND_INITIAL_MBRS 
path, then this issue goes completely away.  So now the questions:

* Why are you passing in a true, and wanting the view only?  Why would 
there be this variation between FIND_ALL and FIND_INITAL?
* If we use FIND_ALL_MBRS....what ends up happening is the discovery 
ends up returning the physical address a split second too late.  I have 
a patch with logging that can illustrate this if your interested.  Given 
the above information, is this what you would expect to happen?  I still 
don't understand why it comes in, just literally milliseconds too late.
* If everything I described is normal, and as it should be.  Will 
FIND_INITIAL_MBRS be reliable enough to try and detect possible 
partitions?  Would another possible solution be to have this boolean be 
passed with the FIND_ALL_MBRS event somehow?  That way we are not forced 
to a true for view only (assuming that it is reasonable to have a false 
value with FIND_ALL_MBRS).

Sorry if it sounds like I don't understand what is going on, it's only 
because I don't, haha.  I just recognize the cause, and am curious if it 
is an error in how I am using JGroups, or if maybe there is some slight 
changes we can do to get the JGroups core to avoid this.  So really just 
looking for guidance based on these findings.  Thanks for your help with 
all this!

Bela Ban wrote:
>
>
> Mike Jensen wrote:
>> Where would the translation between the logical and physical normally 
>> happen?
>
> In TP, using the logical_addr_cache. It is propulated by responses to 
> discovery requests
>
>
>> I ask because it seems odd that if we try again it works, I still 
>> think something might be going&nbsp;on. &nbsp;If&nbsp;you don't mind 
>> I might take a look.
>
> Sure
>
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Javagroups-development mailing list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.