Unfortunately I don't know enough about DNS or more likely the internal membership details of client/server to determine why one part of geode says the hostname is 67.195.81.148 while another part of geode says the hostname is asf904.
DistributedMember.getId() for a client is returning 67.195.81.148 ClientMembershipListener fires events with ClientMembershipEvent and ClientMembershipEvent.getMemberId() is returning asf904 I think this is beyond my knowledge of JMX, management, type stuff and requires someone with client/server membership knowledge to investigate further. I'm not sure why DistributedMember.getId() and ClientMembershipEvent.getMemberId() returns the same value on some asf machines but on other machines one returns ip address while one returns a host name. I don't really know if it's the machine that's wrong, the test code that's wrong or something inside that client membership code. org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest > testSystemClientEventsInServer FAILED org.junit.ComparisonFailure: expected:<[67.195.81.148](13093)<ec><v8>:3277...> but was:<[asf904](13093)<ec><v8>:3277...> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.doTestSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:946) at org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:731) Thanks, Kirk On Tue, Mar 21, 2017 at 12:01 PM, Mark Bretl <asf.mbr...@gmail.com> wrote: > Hi Kirk, > > It looks like the build actually ran on a machine called 'H4', which is > designated as a Hadoop machine. I do not see why running on a Hadoop system > would be an issue, however, I do not know the ASF infrastructure well > enough to know why there are DNS issues. > > We use labels, tied to certain Jenkins nodes, to restrict where we run our > builds, however, if a new system is added to the label, there is not much > we can do. Maybe it is time to work worth INFRA, or some other container, > to get a environment we can rely on all the time? > > --Mark > > On Tue, Mar 21, 2017 at 11:13 AM, Kirk Lund <kl...@apache.org> wrote: > > > Please blacklist asf904 for the Geode nightly job. It seems to be giving > > bad DNS info to our tests, causing UniversalMembershipListenerAda > > pterDUnitTest > > to fail again. Alternatively, if someone else wants to look into the > > failures in UniversalMembershipListenerAdapterDUnitTest please go ahead. > > I've done all I can for the test. > > > > Thanks, > > Kirk > > >