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]> 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]> 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/ >>> [2] https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-notopic/4916/ >>> >>
