I just noticed that the Travis builds do not rebuild the whole project. That is definitely the reason for one of the build failures and probably both. As it stands these builds are worthless.
Ralph > On Jan 26, 2022, at 1:24 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 >>>> >>> >>> >
