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 on. If 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