fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: OracleIT and Rat check failures
Date Thu, 28 Nov 2019 19:29:56 GMT
Okay, so it looks like the failures you're seeing are the result of an old
modules/integration directory that was removed or renamed. Try resetting
your clone with `git clean -fdx`

On Thu, Nov 28, 2019, 00:39 Kenneth McFarland <glorifiedcalculator@gmail.com>
wrote:

> @Christopher : Good, I thought that race condition was fixed in a previous
> issue so I was concerned and should have looked closer. Thank you for the
> catch sir!
>
> I'm still confused as to why the RAT check is throwing errors. I am
> working off a clean master with the same hash as the one Joe mentioned
> (commit 549d645addb330f4ae2e074447428cb86b5a9a3f).
>
>  Here is some environment info:
>
> *MAVEN*
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T00:58:13-07:00)
> Maven home: /opt/apache-maven-3.5.2
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/jdk1.8.0_161/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-70-generic", arch: "amd64", family:
> "unix"
>
> *JAVA*
> openjdk 11.0.5 2019-10-15
> OpenJDK Runtime Environment (build 11.0.5+10-post-Ubuntu-2ubuntu116.04)
> OpenJDK 64-Bit Server VM (build 11.0.5+10-post-Ubuntu-2ubuntu116.04, mixed
> mode, sharing)
>
> I also have a few other java versions installed like the Oracle 1.8.0 that
> maven reports above.
>
> *Operating System*
> Linux ubuntu 4.15.0-70-generic #79~16.04.1-Ubuntu SMP Tue Nov 12 14:01:10
> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> I will try this on my MacI notice the apache-rat setDefaultExcludes
> variable is set to true. I'm currently baffled. The errors are the same if
> I run 'mvn apache-rat:check' or if I run 'mvn verify' or 'mvn clean
> verify''. The logs are kinda large so I simply piped it into a text file,
> as well as included the rat file.
>
>
>
> On Wed, Nov 27, 2019 at 7:06 PM Christopher <ctubbsii@apache.org> wrote:
>
>> I think the stack traces in the logs/test output are intended for that
>> test, because it's specifically checking error handling for a running
>> server (if I remember correctly).
>>
>> On Wed, Nov 27, 2019, 18:42 Joseph Koshakow <koshy44@gmail.com> wrote:
>>
>> > I'm running `mvn clean verify` on the master branch
>> > (549d645addb330f4ae2e074447428cb86b5a9a3f) with OpenJDK 1.8 on Ubuntu
>> 18.04
>> > x86_64. I don't see any issues related to Rat. OracleIT passes and the
>> > entire build is successful, but OracleIT does print the following
>> errors in
>> > the logs
>> >
>> > Running org.apache.fluo.integration.impl.OracleIT
>> > 2019-11-27 18:18:24,087 [thrift.ProcessFunction] ERROR: Internal error
>> > processing getTimestamps
>> > java.lang.IllegalStateException: Received timestamp request but Oracle
>> is
>> > not leader
>> >   at
>> >
>> >
>> org.apache.fluo.core.oracle.OracleServer.getTimestampsImpl(OracleServer.java:244)
>> >   at
>> >
>> >
>> org.apache.fluo.core.oracle.OracleServer.getTimestamps(OracleServer.java:224)
>> >   at
>> >
>> >
>> org.apache.fluo.core.thrift.OracleService$Processor$getTimestamps.getResult(OracleService.java:279)
>> >   at
>> >
>> >
>> org.apache.fluo.core.thrift.OracleService$Processor$getTimestamps.getResult(OracleService.java:257)
>> >   at
>> >
>> >
>> org.apache.fluo.core.shaded.thrift.ProcessFunction.process(ProcessFunction.java:38)
>> >   at
>> >
>> >
>> org.apache.fluo.core.shaded.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
>> >   at
>> >
>> >
>> org.apache.fluo.core.shaded.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:518)
>> >   at
>> >
>> >
>> org.apache.fluo.core.shaded.thrift.server.Invocation.run(Invocation.java:18)
>> >   at
>> >
>> >
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> >   at
>> >
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> >   at java.lang.Thread.run(Thread.java:748)
>> > 2019-11-27 18:18:24,091 [oracle.OracleClient] ERROR: TException
>> occurred in
>> > doWork() method
>> > org.apache.fluo.core.shaded.thrift.TApplicationException: Internal error
>> > processing getTimestamps
>> >   at
>> >
>> >
>> org.apache.fluo.core.shaded.thrift.TServiceClient.receiveBase(TServiceClient.java:79)
>> >   at
>> >
>> >
>> org.apache.fluo.core.thrift.OracleService$Client.recv_getTimestamps(OracleService.java:86)
>> >   at
>> >
>> >
>> org.apache.fluo.core.thrift.OracleService$Client.getTimestamps(OracleService.java:73)
>> >   at
>> >
>> >
>> org.apache.fluo.core.oracle.OracleClient$TimestampRetriever.doWork(OracleClient.java:182)
>> >   at
>> >
>> >
>> org.apache.fluo.core.oracle.OracleClient$TimestampRetriever.run(OracleClient.java:116)
>> >   at java.lang.Thread.run(Thread.java:748)
>> > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.911
>> sec
>> > - in org.apache.fluo.integration.impl.OracleIT
>> >
>> > -Joe
>> >
>> > On Wed, Nov 27, 2019 at 5:18 PM Christopher <ctubbsii@apache.org>
>> wrote:
>> >
>> > > I have not seen any errors with `mvn clean verify` locally, but
>> > > occasionally, there seems to be errors on Travis.
>> > > I'm building the master branch (currently
>> > > 549d645addb330f4ae2e074447428cb86b5a9a3f) with OpenJDK 11 on Fedora 31
>> > > x86_64 with no problems.
>> > >
>> > > On Wed, Nov 27, 2019 at 2:31 PM Kenneth McFarland
>> > > <kennethmcfarland@apache.org> wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > This is just a quick inquiry if anyone else running mvn verify is
>> > getting
>> > > > rat errors that prevent maven from completing.
>> > > >
>> > > >  I'm using -Drat.skip=true to bypass but is this normal?
>> > > >
>> > > > Last thing is OracleIT is throwing errors again. I've checked out
>> the
>> > new
>> > > > code and am building on 16.10 Ubuntu x64.
>> > > >
>> > > > If this is something others are experiencing maybe we can see if
>> there
>> > is
>> > > > an open ticket for OracleIT (thought we closed it with switch on
>> lock
>> > > > implementation in Curator). Rat check is new to me.
>> > > >
>> > > > Thanks a bunch. This is informal, if I'm not insane I'll do a formal
>> > > ticket
>> > > > or something. Again, thanks!
>> > > >
>> > > > Happy holidays also.
>> > > >
>> > > > I
>> > >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message