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.testFlushBehaviorOnFileEvictio > n: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.ServerSocketChannelImpl.bind(ServerSocketChannelI > >>> mpl.java:223) > >>> at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(Ni > >>> oServerSocketChannel.java:127) > >>> at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(Abstrac > >>> tChannel.java:554) > >>> at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(Def > >>> aultChannelPipeline.java:1258) > >>> at io.netty.channel.AbstractChannelHandlerContext.invokeBind(Ab > >>> stractChannelHandlerContext.java:512) > >>> at io.netty.channel.AbstractChannelHandlerContext.bind(Abstract > >>> ChannelHandlerContext.java:497) > >>> at io.netty.handler.logging.LoggingHandler.bind(LoggingHandler. > >>> java:191) > >>> at io.netty.channel.AbstractChannelHandlerContext.invokeBind(Ab > >>> stractChannelHandlerContext.java:512) > >>> at io.netty.channel.AbstractChannelHandlerContext.bind(Abstract > >>> ChannelHandlerContext.java:497) > >>> at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelP > >>> ipeline.java:980) > >>> at io.netty.channel.AbstractChannel.bind( > AbstractChannel.java:250) > >>> at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap > >>> .java:363) > >>> at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(A > >>> bstractEventExecutor.java:163) > >>> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTas > >>> ks(SingleThreadEventExecutor.java:418) > >>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:454) > >>> at io.netty.util.concurrent.SingleThreadEventExecutor$5.run( > >>> SingleThreadEventExecutor.java:873) > >>> at io.netty.util.concurrent.DefaultThreadFactory$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- > notopic/4916/ <https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit- > notopic/4916/> > >>>> > >>> > > > >
