metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject Re: Build failing
Date Mon, 23 Jan 2017 19:09:20 GMT
Yeah, I adjusted the timeout on the indexing integration tests as part of
https://github.com/apache/incubator-metron/pull/420 which I'll merge in
today.

On Mon, Jan 23, 2017 at 2:01 PM, Zeolla@GMail.com <zeolla@gmail.com> wrote:

> Okay, now we have back to back failures, and it looks like it may have been
> a timeout issue?
>  `test(org.apache.metron.solr.integration.SolrIndexingIntegrationTest):
> Took too long to complete: 150582 > 150000`, more details below:
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 166.167 sec <<< FAILURE!
>
> test(org.apache.metron.solr.integration.SolrIndexingIntegrationTest)
> Time elapsed: 166.071 sec  <<< ERROR!
>
> java.lang.RuntimeException: Took too long to complete: 150582 > 150000
>
>         at org.apache.metron.integration.ComponentRunner.process(
> ComponentRunner.java:131)
>
>         at org.apache.metron.indexing.integration.
> IndexingIntegrationTest.test(IndexingIntegrationTest.java:173)
>
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
>         at java.lang.reflect.Method.invoke(Method.java:483)
>
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
>
>         at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
>
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
>
>         at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
>
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
>
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
>
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
>         at org.junit.runners.ParentRunner.runChildren(
> ParentRunner.java:288)
>
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
>         at org.junit.runners.ParentRunner$2.evaluate(
> ParentRunner.java:268)
>
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(
> JUnit4Provider.java:252)
>
>         at org.apache.maven.surefire.junit4.JUnit4Provider.
> executeTestSet(JUnit4Provider.java:141)
>
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> JUnit4Provider.java:112)
>
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
>         at java.lang.reflect.Method.invoke(Method.java:483)
>
>         at org.apache.maven.surefire.util.ReflectionUtils.
> invokeMethodWithArray(ReflectionUtils.java:189)
>
>         at org.apache.maven.surefire.booter.ProviderFactory$
> ProviderProxy.invoke(ProviderFactory.java:165)
>
>         at org.apache.maven.surefire.booter.ProviderFactory.
> invokeProvider(ProviderFactory.java:85)
>
>         at org.apache.maven.surefire.booter.ForkedBooter.
> runSuitesInProcess(ForkedBooter.java:115)
>
>         at org.apache.maven.surefire.booter.ForkedBooter.main(
> ForkedBooter.java:75)
>
>
> Jon
>
> On Thu, Jan 19, 2017 at 2:49 PM Zeolla@GMail.com <zeolla@gmail.com> wrote:
>
> > The build has been showing as failing
> > <https://github.com/apache/incubator-metron> for a little while now.  I
> > know we recently updated the language around Merge Requirements
> > <https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=61332235>,
> > but if I recall properly our current issue is simply a Travis CI overload
> > issue.  Is there a way we can update the wiki doc to account for
> situations
> > like this?
> >
> > Jon
> > --
> >
> > Jon
> >
> > Sent from my mobile device
> >
> --
>
> Jon
>
> Sent from my mobile device
>

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