The last change to ExecSource was in June 2018. I am not sure that what Travis is picking up is valid. The problem I am having with TestKafkaSink is that I have modified the validation method such that every assertion error should generate a custom message. Yet none do. And, in fact, in the code path it should be following it should never perform an assertEquals where expected and actual should have a value of 10.
The second set of test failures are all because the test expects the local hostname to be either “localhost” or “127.0.0.1”. Instead, it is getting a value of ip6-localhost. This is despite my having configured the surefire plugin to be configured with java.net.preferIPv4Stack=true. There are two more errors in TestReliableSpoolingEventReader. For this it looks like events somehow occur in a different sequence on the Travis server then they do on my Mac and my Linux VM. Note that this is also a class that was not touched. Ralph > On Jan 25, 2022, at 3:03 PM, Tristan Stevens <tris...@apache.org> wrote: > > Thanks Ralph. Seems the unit tests are picking up valid problems, which is > reassuring. Curious about execsource although I've got a feeling that did > change since the last release????? > > Tristan > > > > > > On Tue, 25 Jan 2022, 19:03 Ralph Goers, <ralph.go...@dslextreme.com> wrote: > >> There seem to be two builds running and both fail but fail in different >> places. >> >> The first build seems to be failing in a way it shouldn’t. The test is for >> not specifying any Kafka partitions. >> The behavior of how Kafka handles this changed in version 2.4 so it should >> only be checking to see if it >> received all the evants, but it appears it is somehow in the logic to >> check that all the partitions have an >> equal number of events. I’ve added more info into the assert message to >> help diagnose this. >> >> The second build is failing in changes I just made to upgrade Netty & >> Avro. It appears to be failing >> checking the local host name. I will have to add some info to the error to >> determine what it getting for a >> hostname. >> >> I then ran the build in an Ubuntu VM on my MacBook and it got an error in >> TestExecSource (which hasn’t >> been changed). It seems it is calling process.waitFor() and getting a >> returned value of 1. I changed the >> test to call waitFor before calling destroy and it passed. It then failed >> in TestFileChannelRestart giving me >> IOExceptions saying the checkpoint hadn’t completed and the checkpoint >> interval should be increased. >> I added logic to retry in this situation but there is a unit test that >> tries to force that error so I had to have >> it bypass the fix in that case. >> >> I committed those changes and will look at the results of the next Travis >> build to see what additional info >> it can provide. >> >> Ralph >> >> >>> On Jan 24, 2022, at 12:18 AM, Tristan Stevens <tris...@apache.org> >> wrote: >>> >>> Hi all, >>> It seems that for some reason the Travis builds are failing again. One >> of them has been since the Log4j and SLF4J bump (odd) and the other since >> the Kafka upgrade. >>> >>> Anybody got some cycles in investigate whether these are just flaky >> tests and/or whether there’s something more sinister in there? >>> >>> Thanks >>> Tristan >>> >> >>
