You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Xikui Wang <xi...@uci.edu> on 2017/04/01 16:44:27 UTC
Having problem with Gerrit and Jenkins
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/
Re: Having problem with Gerrit and Jenkins
Posted by abdullah alamoudi <ba...@gmail.com>.
I have seen the sonar qube one in a few of my recent changes.
However, I didn't get any failures that were not caused by a bug in the change.
Cheers,
Abdullah.
> On Apr 1, 2017, at 9:44 AM, Xikui Wang <xi...@uci.edu> 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/
Re: Having problem with Gerrit and Jenkins
Posted by Xikui Wang <xi...@uci.edu>.
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 <xi...@uci.edu> 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 <ba...@gmail.com>
> 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 <ba...@gmail.com>
>> 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 <xikuiw@uci.edu <mailto:
>> xikuiw@uci.edu>> 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 <tillw@apache.org
>> <ma...@apache.org>> 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/>
>> >>>>
>> >>>
>> >
>>
>>
>
Re: Having problem with Gerrit and Jenkins
Posted by Xikui Wang <xi...@uci.edu>.
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 <ba...@gmail.com>
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 <ba...@gmail.com>
> 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 <xikuiw@uci.edu <mailto:
> xikuiw@uci.edu>> 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 <tillw@apache.org
> <ma...@apache.org>> 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/>
> >>>>
> >>>
> >
>
>
Re: Having problem with Gerrit and Jenkins
Posted by abdullah alamoudi <ba...@gmail.com>.
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 <ba...@gmail.com> 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 <xikuiw@uci.edu <ma...@uci.edu>> 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 <tillw@apache.org <ma...@apache.org>> 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/>
>>>>
>>>
>
Re: Having problem with Gerrit and Jenkins
Posted by abdullah alamoudi <ba...@gmail.com>.
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 <xi...@uci.edu> 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 <ti...@apache.org> 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/
>>>
>>
Re: Having problem with Gerrit and Jenkins
Posted by Xikui Wang <xi...@uci.edu>.
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 <ti...@apache.org> 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/
>>
>
Re: Having problem with Gerrit and Jenkins
Posted by Till Westmann <ti...@apache.org>.
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(ServerSocketChannelImpl.java:223)
at
io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:127)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:554)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1258)
at
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:512)
at
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:497)
at
io.netty.handler.logging.LoggingHandler.bind(LoggingHandler.java:191)
at
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:512)
at
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:497)
at
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.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(AbstractEventExecutor.java:163)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(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$DefaultRunnableDecorator.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/