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

Yes in init(). Use a setter or call setValue()

Sent from my HTC

----- Reply message -----
From: "Mike Jensen" <[email protected]>
Date: Fri, Oct 8, 2010 5:53 pm
Subject: [jgroups-dev] https://jira.jboss.org/browse/JGRP-1240
To: "Bela Ban" <[email protected]>
Cc: "jg-dev" <[email protected]>


I assume the correct place to do this is in init()?

Once I have a handle on the protocol, how should I set the value?  I see setProperty(string, string) is depreciated.

Bela Ban wrote:
> You could leave the default config untouched, but - after new > JChannel(), and before calling JChannel.connect() - grab the discovery > protocol and set those values programmatically...
>
>
> Mike Jensen wrote:
>> I have gone ahead and did the XML configuration changes you >> suggested.  That seems to work just fine.  My only concern now is >> that this makes it even more dependent on a very specific XML >> configuration.  Changing values which seem innocent, may have >> repercussions that users wont understand.  Is there any way to >> protect these configured values for Discovery from within my protocol?
>>
>> Thanks for your help.
>>
>> Bela Ban wrote:
>>  >>> Mike Jensen wrote:
>>>    >>>> 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?
>>>>       >>> FIND_INITIAL_MBRS is used for initial discovery. It is designed to >>> return as quickly as possible *and* to return mappings between the >>> logical and physical address. By default, this returns as soon as we >>> get a response from a coord (break_on_coord_rsp=true by default).
>>>
>>> FIND_ALL_MBRS is used by MERGE2 to periodically see if we have >>> partitions. This is done exclusively on views, but we cannot return >>> when we get a response from a coord, because we need as many

------------------------------------------------------------------------------
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