Re: [jgroups-users] Flush + tcp Configuration

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