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 <kosh...@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 <ctubb...@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 > > <kennethmcfarl...@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 > > >
