Re: [jgroups-users] Flush + tcp Configuration

On 07/08/18 11:49, Questions/problems related to using JGroups wrote:
> Hello,
> 
> We are using a ReplicatedHashMap to publicate the health/version of a 
> node. So not much more than a list of all active nodes in a cluster.
> If we are using a UDP based Configuration it works pretty well, if we 
> are using a TCP based Configuration we often see nodes that have been 
> shut down as active or we are missing nodes that are definitly up and 
> running. 

This should not be an issue. You should look into the following things:
- Failure detection (FD_ALL instead of FD, FD_SOCK) and timeouts
- TCPPING: did you include all host:port combinations (hosts only on 
7800 and 7801?)
- Configuration of transport's thread pools
- Merge config

> I am still trying to figuring out what the underlying issue is.
> 
> Best regards,
> Thorsten Goetzke
> 
> 
> Am 07.08.18 um 10:56 schrieb Questions/problems related to using JGroups:
>>
>>
>> On 07/08/18 10:52, Questions/problems related to using JGroups wrote:
>>> Hello,
>>>
>>> Thanks for your answer. You are correct FLUSH isn't the culprit here, 
>>> tcp.bind_addr is. The original tcp.xml provided by jgroups doesn't 
>>> use tcp.bind_addr. I added bind_addr=127.0.0.1 to config and now the 
>>> nodes are finding eachother with or without FLUSH.
>>
>> OK
>>
>>> So the way it works is one has to set bind_addr to the same value as 
>>> in initial_hosts, either both pointing to the Loopback address or 
>>> both pointig to a real ip adress and not mixing between these two.
>>
>> Correct. Alternatively, you could use a different (dynamic) discovery 
>> protocol.
>>
>> Note that FLUSH is old and (semi-) unsupported; do you really need it? 
>> What properties do you need from the reliable transport?
>>
>>> Best regards,
>>> Thorsten Goetzke
>>>
>>> Am 06.08.18 um 18:02 schrieb Questions/problems related to using 
>>> JGroups:
>>>>
>>>>
>>>> On 03/08/18 17:21, Questions/problems related to using JGroups wrote:
>>>>> Hello,
>>>>>
>>>>> I am currently trying to get Jgroups running reliable using the tcp 
>>>>> protocol. Now here is a problem that i ran into:
>>>>> Initially we used the tcp.xml provided by jgroups (assuming that 
>>>>> that config would be a good starting point) and added pbcast.FLUSH.
>>>>> That actually didn't work. I ran the ReplicatedHasMapDemo on this 
>>>>> config using 2 clients on port 7800 and 7801 respectively. The 
>>>>> title for both clients stayed at 1 Server(s), so the Demo didn't work
>>>>
>>>>
>>>> Using FLUSH or not should not make a diff in discovery; make sure 
>>>> that 'localhost' maps to 127.0.0.1 (as you set your bind address to 
>>>> it), and also verify jgroups.tcp.bind_port maps to 7800 and 7801, 
>>>> respectively.
>>>>
>>>> By just adding FLUSH, you probably had a mismatch between 
>>>> TCP.bind_addr/bind_port and TCPPING.initial_hosts
>>>>
>>>>
>>>>> Than I wrote the config below and the Demo did work.
>>>>> So i am currently somewhat lost. Is this behavior a bug, was the 
>>>>> configuration just wrong, is my new configuration any good...
>>>>>
>>>>> I tried to find some information online, apperently once apon a 
>>>>> time a tcp-flush.xml existed but it got removed(?) There seems to 
>>>>> be some information on javagroups-cvs but thats private(?)
>>>>>
>>>>> Our Usecase: A very small amount of servers publishing their state, 
>>>>> little traffic but reliablity (especially when servers are 
>>>>> unplugged/rebooted) is pretty important.
>>>>>
>>>>> Best Regards,
>>>>> Thorsten Goetzke
>>>>>
>>>>> <config xmlns="urn:org:jgroups"
>>>>>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>          xsi:schemaLocation="urn:org:jgroups 
>>>>> http://www.jgroups.org/schema/jgroups.xsd">
>>>>>
>>>>> <TCP
>>>>>          bind_addr="127.0.0.1"
>>>>>          bind_port="${jgroups.tcp.bind_port}"
>>>>> />
>>>>>
>>>>> <!-- it is recommended to add all the hosts on which members of the 
>>>>> cluster will be running to the configuration. -->
>>>>> <TCPPING async_discovery="true"
>>>>>
>>>>> initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800],localhost[7801],localhost[7802]}" 
>>>>>
>>>>>           port_range="0"/>
>>>>>
>>>>> <MERGE3 />
>>>>> <FD_SOCK/>
>>>>> <FD/>
>>>>> <VERIFY_SUSPECT/>
>>>>> <BARRIER/>
>>>>> <pbcast.NAKACK2 />
>>>>> <UNICAST3 />
>>>>> <pbcast.STABLE />
>>>>> <pbcast.GMS />
>>>>> <MFC/>
>>>>> <FRAG2 />
>>>>> <RSVP />
>>>>> <pbcast.STATE_TRANSFER/>
>>>>> <pbcast.FLUSH/>
>>>>> </config>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> javagroups-users mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>>>
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> javagroups-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>
> 
> ------------------------------------------------------------------------------ 
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users

-- 
Bela Ban | http://www.jgroups.org


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users