You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Guanghao Zhang (Jira)" <ji...@apache.org> on 2020/08/12 05:59:00 UTC
[jira] [Commented] (HBASE-23850) [Flakey Test]
TestAsyncTableRSCrashPublish times out VPN enabled
[ https://issues.apache.org/jira/browse/HBASE-23850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176029#comment-17176029 ]
Guanghao Zhang commented on HBASE-23850:
----------------------------------------
[~stack] I meet this failed ut many times too. How about ignore this?
> [Flakey Test] TestAsyncTableRSCrashPublish times out VPN enabled
> ----------------------------------------------------------------
>
> Key: HBASE-23850
> URL: https://issues.apache.org/jira/browse/HBASE-23850
> Project: HBase
> Issue Type: Bug
> Reporter: Michael Stack
> Priority: Major
>
> This is an odd one. If I put up VPN on my local machine, this TestAsyncTableRSCrashPublish test times out. If I take down the VPN, the test passes. This is actually an awkward issue to trace since the udp multicast stuff doesn't log much about its operation. Digging, the VPN adds a utun8 network interface to my box. When this eighth interface comes on line, the TestAsyncTableRSCrashPublish test will select this new interface, which is ipv4, for the master to publish events on, but the clients will choose the seventh utun interface, which is ipv6, for listening. If no vpn, both pick an en?? interface and all just works. I've messed around with the test and tried having the master add the networkinterface its chosen to the configuration, and then had the clients use same network interface, but somehow clients insist on listening on ipv6. No matter how I mess -- even insisting on ipv4 on client and server (see coming attached code), the clients don't get the master broadcast.
> Attached code is my hacking trying to make sense of this. Let me make a trivial subtask to add the logging at least in case someone runs into this in prod, they'll have a chance for figuring out mismatched networking (currently there is no way to figure w/o changing code).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)