Update: I tried "mvn test" locally and it ran successfully. I ended up with creating a new branch with the same changes. Submitting this branch solved the compilation error. :) Thanks for all your help.
On Sat, Apr 1, 2017 at 11:14 AM, Xikui Wang <[email protected]> wrote: > Hi Abdullah, Thanks! Running the updated the tests now. > > btw, I noticed that my build is running on cb-jenkins-6 > <https://asterix-jenkins.ics.uci.edu/computer/cb-jenkins-6>, but other > active patches on gerrit are on docker. Could this be a possible reason? > > Best, > Xikui > > On Sat, Apr 1, 2017 at 11:06 AM, abdullah alamoudi <[email protected]> > wrote: > >> P.S >> >> If anyone runs this test locally, it will pass the first time (assuming >> target is clean) and then will fail until target is cleaned. Somehow, this >> test/build was done on a non-clean target. mblow or imaxon might have an >> idea as to why. >> >> Cheers, >> Abdullah. >> >> > On Apr 1, 2017, at 11:02 AM, abdullah alamoudi <[email protected]> >> wrote: >> > >> > Xikui, >> > The failure in the BufferCacheRegressionTest is a false positive I >> think. There is a bug in the test that I have fixed in >> https://asterix-gerrit.ics.uci.edu/#/c/1619/ < >> https://asterix-gerrit.ics.uci.edu/#/c/1619/> but that change is yet to >> be reviewed.. >> > You can pick the fix from there. >> > >> > Cheers, >> > Abdullah. >> > >> >> On Apr 1, 2017, at 10:56 AM, Xikui Wang <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> >> Hi Till, >> >> >> >> I went through the log on Jenkins. The "Address already in use" >> exception >> >> firstly occurs in hyracks-client package. That works fine locally when >> I >> >> run "mvn test" on my machine. But my local test failed at >> >> "hyracks-storage-common-test" which I think is not related to my >> change as >> >> well... >> >> >> >> Failed tests: >> >> >> >> BufferCacheRegressionTest.testFlushBehaviorOnFileEviction: >> 71->flushBehaviorTest:131 >> >> Page 0 of deleted file was fazily flushed in openFile(), corrupting the >> >> data of a newly created file with the same name. >> >> >> >> >> >> Best, >> >> Xikui >> >> >> >> On Sat, Apr 1, 2017 at 9:53 AM, Till Westmann <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> Hi Xikui, >> >>> >> >>> If you look at the failures, you’ll see that the error is >> >>> >> >>> java.net.BindException: Address already in use >> >>> at sun.nio.ch.Net.bind0(Native Method) >> >>> at sun.nio.ch.Net.bind(Net.java:433) >> >>> at sun.nio.ch.Net.bind(Net.java:425) >> >>> at sun.nio.ch.ServerSocketChannel >> Impl.bind(ServerSocketChannelI >> >>> mpl.java:223) >> >>> at io.netty.channel.socket.nio.Ni >> oServerSocketChannel.doBind(Ni >> >>> oServerSocketChannel.java:127) >> >>> at io.netty.channel.AbstractChann >> el$AbstractUnsafe.bind(Abstrac >> >>> tChannel.java:554) >> >>> at io.netty.channel.DefaultChanne >> lPipeline$HeadContext.bind(Def >> >>> aultChannelPipeline.java:1258) >> >>> at io.netty.channel.AbstractChann >> elHandlerContext.invokeBind(Ab >> >>> stractChannelHandlerContext.java:512) >> >>> at io.netty.channel.AbstractChann >> elHandlerContext.bind(Abstract >> >>> ChannelHandlerContext.java:497) >> >>> at io.netty.handler.logging.Loggi >> ngHandler.bind(LoggingHandler. >> >>> java:191) >> >>> at io.netty.channel.AbstractChann >> elHandlerContext.invokeBind(Ab >> >>> stractChannelHandlerContext.java:512) >> >>> at io.netty.channel.AbstractChann >> elHandlerContext.bind(Abstract >> >>> ChannelHandlerContext.java:497) >> >>> at io.netty.channel.DefaultChanne >> lPipeline.bind(DefaultChannelP >> >>> ipeline.java:980) >> >>> at io.netty.channel.AbstractChannel.bind(AbstractChannel.java: >> 250) >> >>> at io.netty.bootstrap.AbstractBoo >> tstrap$2.run(AbstractBootstrap >> >>> .java:363) >> >>> at io.netty.util.concurrent.Abstr >> actEventExecutor.safeExecute(A >> >>> bstractEventExecutor.java:163) >> >>> at io.netty.util.concurrent.Singl >> eThreadEventExecutor.runAllTas >> >>> ks(SingleThreadEventExecutor.java:418) >> >>> at io.netty.channel.nio.NioEventL >> oop.run(NioEventLoop.java:454) >> >>> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run( >> >>> SingleThreadEventExecutor.java:873) >> >>> at io.netty.util.concurrent.Defau >> ltThreadFactory$DefaultRunnabl >> >>> eDecorator.run(DefaultThreadFactory.java:144) >> >>> at java.lang.Thread.run(Thread.java:745) >> >>> >> >>> So the test could not start AsterixDB and a probable reason is that a >> >>> previous test was not able to shut down. I would expect that you see >> the >> >>> same result if you run the tests locally. >> >>> >> >>> Is that the case? >> >>> >> >>> Cheers, >> >>> Till >> >>> >> >>> >> >>> On 1 Apr 2017, at 9:44, Xikui Wang wrote: >> >>> >> >>> Good morning Devs, >> >>>> >> >>>> I am having a problem with one patch [1] on Gerrit and Jenkins. The >> >>>> SonarQube violation detected is not in the patched code, but in the >> >>>> original code. Also, the Jenkins Job keeps failing on test cases >> which >> >>>> seem >> >>>> to be not related to the change [2]. I have tried to abandon and >> resubmit >> >>>> it as a new patch, but the problem remains. Has anyone had similar >> issue >> >>>> before? Thanks! >> >>>> >> >>>> Best, >> >>>> Xikui >> >>>> >> >>>> >> >>>> [1] https://asterix-gerrit.ics.uci.edu/#/c/1648/ < >> https://asterix-gerrit.ics.uci.edu/#/c/1648/> >> >>>> [2] https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-notop >> ic/4916/ <https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-noto >> pic/4916/> >> >>>> >> >>> >> > >> >> >
