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

Reply via email to