Re: [jgroups-users] why is a random number added to the hostname in util#generateLocalName + impact

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Gennady,

Thanks. It certainly provided some additional insights. I have incorporated those insights into my solution. Unfortunately there is still one case, where it goes wrong, and that’s the case where a former coordinator node rejoins the cluster and takes over ownership(thus becomes coordinator again). It’s not clear to me why that particular node reclaims coordination ownership. Anyway, we will probably replace file ping by tcp ping.

From: Gennady Shumakher [mailto:gsh...@gm...]
Sent: zaterdag 10 januari 2015 2:09
To: Questions/problems related to using JGroups
Subject: Re: [jgroups-users] why is a random number added to the hostname in util#generateLocalName + impact on fileping discovery after kill -9

David,
I've implemented a custom Address generator. Something like following:

/**
 * Custom jgroup {@link Address} generator to create stable address based on specific machine IP.
 */
public class StableIPBasedJGAddressGenerator implements AddressGenerator, Serializable {
         private static final long serialVersionUID = 1L;

         @Override
         public Address generateAddress() {
                   try {
                            String ip = org.jgroups.util.Util.getAddress(AddressScope.NON_LOOPBACK).getHostAddress();
                            java.util.UUID jUuid = java.util.UUID.nameUUIDFromBytes(ip.getBytes());
                            return org.jgroups.util.UUID.fromString(jUuid.toString());
                   } catch (SocketException ex) { // log exception?
                            return org.jgroups.util.UUID.randomUUID();
                   }
         }
}

then during channel initialization:
JChannel channel = new JChannel(stackConfig);
channel.addAddressGenerator(new StableIPBasedJGAddressGenerator());
....
channel.connect();

I hope this helps.

--Gennady

On Fri, Jan 9, 2015 at 12:44 PM, David Cypers <DC...@ex...<mailto:DC...@ex...>> wrote:
Thanks Gennady. Based on your information I did some further investigation.

So, if I understand it correctly, I can set a custom address generator via myChannel#addressGenerator(..) before the connection is made.

However, to achieve a “stable name”, do I also need to write a custom implementation of Address, or can I just plug in the IpAddress implementation of the Address interface into my custom AddressGenerator implementation? Or are there any gotchas under the hood?

In Short:

-          Create custom address generator

-          Use IpAddress implementation

-          Solves manual cleanup issue after kill -9 when using eg. FILE_PING ?

From: Gennady Shumakher [mailto:gsh...@gm...<mailto:gsh...@gm...>]
Sent: vrijdag 9 januari 2015 6:35
To: Questions/problems related to using JGroups
Subject: Re: [jgroups-users] why is a random number added to the hostname in util#generateLocalName + impact on fileping discovery after kill -9

Hi David,
I had the same issue with JDBC_PING in the development environment while running single node with eventually killed process. The solution I've came with was to use a custom AddressGenerator that creates a stable name out of hostname rather to go with the random name generated by default. So since the same name is generated on every run, only one record is maintained and startup time is not affected.

--Gennady

On Wed, Jan 7, 2015 at 5:37 PM, David Cypers <DC...@ex...<mailto:DC...@ex...>> wrote:
Ok, thanks a lot!

I consider this thread as closed.

-----Original Message-----
From: Bela Ban [mailto:be...@ya...<mailto:be...@ya...>]
Sent: woensdag 7 januari 2015 16:25
To: jav...@li...<mailto:jav...@li...>
Subject: Re: [jgroups-users] why is a random number added to the hostname in util#generateLocalName + impact on fileping discovery after kill -9

Yes, if you kill -9, all file based protocols (JDBC_PING is a subclass) require manual cleanup.

On 07/01/15 16:05, David Cypers wrote:
> Hi Bela,
>
> Jchannel#setName indeed did not solve the issue. I was wrongly assuming that if the logical name and the physical address were the same, that no entry would be added (based on the docs of FILE_PING#addDiscoveryResponseToCaches which I might have misinterpreted).
>
> Example file after a few kills, with fixed name:
>
> DAVID-D7D       1a92f689-18b5-2678-1af5-a00c7a74588d    127.0.0.1:7840<http://127.0.0.1:7840>  T
> DAVID-D7D       286fd7c9-4416-1666-9e2c-c20c18b08def    127.0.0.1:7840<http://127.0.0.1:7840>  F
>
> I guess JDBC_PING suffers with the same problem, and also requires manual cleanup after a kill -9?
>
>
> David Cypers
> External Consultant: IT Software Factory || DC...@ex...<mailto:DC...@ex...>
> Tel :  +32 +32 2 5451 711<tel:%2B32%202%205451%20711>
>
> Isabel NV/SA www.isabel.eu<http://www.isabel.eu> www.zoomit.be<http://www.zoomit.be> RPM Brussel BE 0455 530 509
> RPR Bruxelles Disclaimer :
> www.isabel.be/support6/en-US/disclaimer/index.php<http://www.isabel.be/support6/en-US/disclaimer/index.php>
>
> -----Original Message-----
> From: Bela Ban [mailto:be...@ya...<mailto:be...@ya...>]
> Sent: woensdag 7 januari 2015 15:38
> To: jav...@li...<mailto:jav...@li...>
> Subject: Re: [jgroups-users] why is a random number added to the
> hostname in util#generateLocalName + impact on fileping discovery
> after kill -9
>
> Hi David,
>
> if you use kill -9 to kill a member P, then you have to manually remove P's file.
>
> The generation of the random name is not important; it's just used for naming and we use the UUID as address. Note that you can name a name with JChannel.setName(String name).
>
> I fails to see a causal link between logical name and having to to manually remove the file of a node killed with -9...
>
> On 07/01/15 14:58, David Cypers wrote:
>> *Problem:*
>> *Application start-up becomes slower and slower after kill -9 because
>> the FILE_PING ‘members file’ is not cleaned up.*
>
>> *Our setup:*
>> *On our local dev machine, we have jgroups configured using FILE_PING.
>> We only have one node deployed.*
>
>> *When we kill the application, and restart it, it takes more time to
>> get the application started, because our node was not removed from
>> the ‘members file’. *
>>
>> *When we start the application again, a new entry is made into the
>> ‘members file’, and jgroups starts to discover the other listed
>> nodes.*
>>
>> *Example ‘members file’ after a few kills:*
>>
>> **
>>
>> *DAVID-D7D-37395   aac013ed-2fd3-782f-6350-3fe4e7e50375    168.47.46:7800      T*
>> *DAVID-D7D-45995   fb1878db-a3af-0fd2-aaa1-62a384af1b8e     168.47.46:7800      F*
>> *DAVID-D7D-36551   ed8400da-5a34-5188-3518-6a184756a3b6 168.47.46:7800      F*
>>
>> **
>>
>> *This is also documented on
>> https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedD
>> i
>> scovery.txt*
>>
>> **
>>
>> - If we have {A,B,C,D}, and A crashes or leaves, and B becomes the
>> new coordinator, then
>>
>>     - A removes A.list (including info on A,B,C,D) by means of a
>> shutdown hook (kill -9 requires manual cleanup)
>>
>> **
>>
>> *However, according to the documentation of
>> FILE_PING#addDiscoveryResponseToCaches, manual cleanup should not be
>> required, because the documentation for
>> FILE_PING#**addDiscoveryResponseToCaches
>> <http://www.jgroups.org/javadoc/org/jgroups/protocols/FILE_PING.html#<http://www.jgroups.org/javadoc/org/jgroups/protocols/FILE_PING.html>
>> a
>> ddDiscoveryResponseToCaches-org.jgroups.Address-java.lang.String-org.
>> j groups.PhysicalAddress->**says that “*Only add the discovery
>> response if the logical address is not present or the physical addrs
>> are different”
>>
>> As seen in the example above, our physical address remains the same.
>> I would assume that my logical address(host name) would also be
>> invariant, however, this is not the case!
>>
>> That’s because the code for Util#generateLocalName randomly adds a
>> number to the hostname.
>>
>> *public static *String generateLocalName() { ..
>> retval=/shortName/(InetAddress./getLocalHost/().getHostName());
>>       ..
>>
>> *long *counter=Util./random/(Short.*/MAX_VALUE /** 2); *return
>> *retval
>> + *"-" *+ counter; }
>>
>> Now, my questions are:
>>
>> a)Why is this done? Is there any good reason to introduce a little
>> bit of randomness?
>>
>> b)Can the randomness be removed in a future release?
>>
>> c)If not, are we forever stuck to manual intervention in case of kill -9 ?
>>
>> I guess, removing the randomness, will not give problems in case you
>> want to deploy 2 nodes on the same machine;  the node will still be
>> added (see *FILE_PING#addDiscoveryResponseToCaches) because your
>> second node will have a different port-number in your physical
>> address.*
>>
>> **
>>
>> Thanks,
>>
>> David
>>
>> David**Cypers
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> javagroups-users mailing list
> jav...@li...<mailto:jav...@li...>
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> javagroups-users mailing list
> jav...@li...<mailto:jav...@li...>
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

--
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
javagroups-users mailing list
jav...@li...<mailto:jav...@li...>
https://lists.sourceforge.net/lists/listinfo/javagroups-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
javagroups-users mailing list
jav...@li...<mailto:jav...@li...>
https://lists.sourceforge.net/lists/listinfo/javagroups-users

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
javagroups-users mailing list
jav...@li...<mailto:jav...@li...>
https://lists.sourceforge.net/lists/listinfo/javagroups-users