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.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/>
>>>> 
>>> 
> 

Reply via email to