./gradlew check hanging
Opened this issue · 35 comments
After running the command ./gradlew check, the execution hangs during test, output is shown below. I am running the command as admin. Even after leaving the system for whole day.
What could be the reason for this, and how can I fix it ?
/yodaqa-master]$ ./gradlew check
:generateTypeSystem UP-TO-DATE
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:generateTestTypeSystem UP-TO-DATE
:compileTestJava UP-TO-DATE
:compileTestGroovy UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED
Building 83% > :test
I have the same error it hang on Building 83%, but it hang if I run
echo | ./gradlew run
and not ./gradlew check this run well
i have winodws 8.1 64 Bit
Oh, seems like my replies were going just to the original submitter instead of this issue, oops.
- Please try running it with -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug and paste the last few messages
- Please verify your IPv6 connectivity is working or IPv6 is disabled. (Does http://ipv6.whatismyv6.com/ hang on "Connecting..."?)
- If you use HTTP proxy, make sure it's set up correctly or try without it.
Please let me know if there's anything new. Even if you've solved this, too!
I know this issue is closed - but I'm running into a similar problem. It hangs for me at 83% while running
echo | ./gradlew run
Here are the last few lines from the output:
INFO ResourceObjectProviderBase - Producing resource from jar:file:/root/.ivy2/cache/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-person/jars/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-person-20130624.jar!/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/ner-en-person.bin
INFO ResourceObjectProviderBase - Used resource from cache
INFO ResourceObjectProviderBase - :: loading settings :: url = jar:file:/root/.gradle/caches/modules-2/files-2.1/org.apache.ivy/ivy/2.3.0/c5ebf1c253ad4959a29f4acfe696ee48cdd9f473/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
INFO ResourceObjectProviderBase - Producing resource from jar:file:/root/.ivy2/cache/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-person/jars/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-person-20130624.jar!/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/ner-en-person.bin
INFO ResourceObjectProviderBase - Used resource from cache
INFO ResourceObjectProviderBase - :: loading settings :: url = jar:file:/root/.gradle/caches/modules-2/files-2.1/org.apache.ivy/ivy/2.3.0/c5ebf1c253ad4959a29f4acfe696ee48cdd9f473/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
INFO ResourceObjectProviderBase - Producing resource from jar:file:/root/.ivy2/cache/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time/jars/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time-20100907.jar!/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/ner-en-time.bin
INFO ResourceObjectProviderBase - Used resource from cache
INFO ResourceObjectProviderBase - :: loading settings :: url = jar:file:/root/.gradle/caches/modules-2/files-2.1/org.apache.ivy/ivy/2.3.0/c5ebf1c253ad4959a29f4acfe696ee48cdd9f473/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
INFO ResourceObjectProviderBase - Producing resource from jar:file:/root/.ivy2/cache/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time/jars/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time-20100907.jar!/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/ner-en-time.bin
INFO ResourceObjectProviderBase - Used resource from cache
> Building 83% > :run
It always stops while producing a resource from ner-en-time.bin. I'm running this in an EC2 instance, not using a proxy (that I'm aware of) and have disabled ipv6. I do see a few errors in the output as well - there is an exception relating to enwiki not being available at http://enwiki.ailao.eu:8983/solr as well as the following:
ERROR ResourceObjectProviderBase - :: problems summary ::
ERROR ResourceObjectProviderBase - :::: ERRORS
ERROR ResourceObjectProviderBase - unknown resolver null
ERROR ResourceObjectProviderBase - unknown resolver null
Any ideas, things for me to try?
It probably hanged because of the enwiki not being available. And that was the case as some prankster logged into the admin interface (which I thought is available only via localhost) and renamed the enwiki core (and hopefully did nothing else)... Yay. Now I'll need to figure out how the heck to configure solr to disable this...
If the problem persists, please include complete output with debugging enabled.
Not sure whether it's directly related, but I experienced a rather similar issue (also stopped at 83%, same last messages) that was actually caused by an exception earlier on. When you enable unlimited buffering in your terminal and scroll up you might see an exception about some DKpro component not found in your Maven repository [FileNotFoundException for classpath:/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/sentence-en-maxent.properties, I think - it should say something like org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl callAnalysisComponentProcess(417) SEVERE: Exception occured shortly before and then print the typical stack trace afterwards]. Here is where it gets muddy, though. I just ran and reran the YodaQA commands a few times and the exception vanished. Once it does, it should never appear again. Happened to me on a few machines / images / VM instances afair. [Interestingly, even though I usually copy over my .m2 and .gradle caches.]
Please reopen this issue.
I reproduced the error today, so it's not caused by enwiki. When I build YodaQA 1.4 I run into the same exception. Actually asking 3 questions via "./gradlew run -q" reliably fixes this: I have reproduced the error twice by creating a new Docker container and I didn't do anything besides Ctrl-c after YodaQA got stuck and immediately rerunning "./gradlew run -q" to ask the same question. Both times on the third iteration - as esoterically as it sounds - the error vanished and never reoccurred.
Maybe WON'T FIX, because it's cool that you need to know the secret ritual to launch it? 😁
Hi! Thanks for all the reports. I'll reopen this issue as what you describe should really be fixed; though I never noticed anything like this before on the systems where I ran YodaQA. :(
I think for newcomers to this issue, the important message is that multiple causes may cause the run hanging. The bottom line is that the hang is caused by an exception earlier (possibly way above in the scrollback, try running with ... 2>&1 | tee log.txt), which can itself be caused by:
- Network connectivity issues; e.g. related to http proxy or IPv6 connectivity.
- Downtime on our side, where some of the public database instances are undergoing service or whatever.
- Problem with some NLP resources not being downloaded properly the first time, try re-issuing run a few times as @jbauer180266 suggests.
- A genuine bug, of course.
I get a hang on ./gradle run at the same point as @jspalink with a message relating to the production of ner-en-time.bin immediately proceeding the hang.
- I have checked my IPv6 connectivity and everything looks good
- I am not using a proxy
- your solr service seems to be available (though it does show the following error message at the top of the page)
SolrCore Initialization Failures:
new_core: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load config file /home/pasky/src/brm/brmson/solr-4.6.0/example/enwiki/new_core/solrconfig.xml
edit: I ran run with -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug and these are the last few lines before the hang:
INFO ResourceObjectProviderBase - Producing resource from jar:file:/Users/szednik/.ivy2/cache/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time/jars/de.tudarmstadt.ukp.dkpro.core.opennlp-upstream-ner-en-time-20100907.jar!/de/tudarmstadt/ukp/dkpro/core/opennlp/lib/ner-en-time.bin
INFO ResourceObjectProviderBase - Used resource from cache
DEBUG PipelineLogger - QA analysis
DEBUG LblTreeCASFactory - --- no dependency tree roots
Hi! Anyone who runs into such a problem, please do include (e.g. link to pastebin) the full output. The last few preceding lines are pretty much always irrelevant to the problem. Even the last exception, if you see any, will be irrelevant. The first exception that happens throughout the whole run is indicative of what the problem is. (If there is no exception, that'd be another problem yet altogether.)
I don't want to be irrationally optimistic here, but has anyone experienced this error lately, esp. on the 1.5 release? Because I haven't...
Maybe this can be closed if nobody confirms or reports new occurrences over the next two weeks?
cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED
Building 83% > :test
Same here. So, is it a proxy issue? or bug?
Apparently, we had some trouble with connectivity of a couple of our services last night. Does the problem persist? Have you tried just running gradle a couple of times?
Still problematic. Is there way to install everything on local machine and test QA system? (instead of connect to remote server or w/o any dependencies).
Bad news: My ritual does not work anymore and I cannot run YodaQA anymore. The dependency de.tudarmstadt.ukp.dkpro.core.opennlp-model-sentence-en-maxent:20120616.1 cannot be found anywhere, as before. Any suggestions how to proceed?
Not surprising, cmp. http://mvnrepository.com/artifact/de.tudarmstadt.ukp.dkpro.core/de.tudarmstadt.ukp.dkpro.core.opennlp-model-sentence-en-maxent
Gives 404. Maybe host it yourself like eij for BlanQA? Or get rid of it - it seems to be a testing dependency only.
The file seems to be also here: https://zoidberg.ukp.informatik.tu-darmstadt.de/jenkins/job/DKPro%20Core%20Documentation%20%28GitHub%29/de.tudarmstadt.ukp.dkpro.core$de.tudarmstadt.ukp.dkpro.core.doc-asl/doclinks/5/#model-de.tudarmstadt.ukp.dkpro.core.opennlp-model-sentence-en-maxent But I haven't been able to inject it into my Gradle cache so far.
PS:
Being a bit proactive, I have asked about this on the DKPro mailing list, cmp. https://groups.google.com/forum/#!topic/dkpro-core-user/RFPOCgBT7V4
PPS:
Heh. I just pulled the docker image containerx/yodaqa (the only one I could find) and it complains about not finding de.tudarmstadt.ukp.dkpro.core.stanfordnlp-model-tagger-en-bidirectional-distsim 20140616.1 YodaQA seems to be completely broken at the current point in time. I think this bug should get critical severity. I honestly cannot get it to run. I will now have to turn to a colleague's old machine that was once able to compile it and hope for the best.
PPPS:
So I've extracted the libraries from a machine where Yoda was successfully compiled before and tried to somehow copy over the missing dependency. Cloning .gradle didn't work (as expected; also with --offline) and copying all libraries into a folder via
task copyRuntimeLibs(type: Copy) {
into "libsTest"
from configurations
}
and then using it via
flatDir {
dirs 'libsTest'
}
in repositories also didn't help.
Thus, I currently see no way to use Yoda. Please get back to me about this asap. Thanks.
The file should be available again from zoidberg (http://zoidberg.ukp.informatik.tu-darmstadt.de/artifactory/public-model-releases-local) once its maintenance is complete. We do not plan to upload this file (or any other model files) to Maven Central for the time being. The problem is, that most model files are in a somewhat grey area when it comes to their license status. To upload something on Maven Central (or Bintray), we would have to know pretty well which licensed these artifacts are under. People using Maven intensively are strongly encouraged to set up caching/proxy repositories to maintain copies of the artifacts they require (not only DKPro Core artifacts, but any artifacts).
Works. Amazing, thank you so much.
Argh. Thanks for the heads-up, seems like someone again renamed the core from "collection1" recently, this has happenned before but unfortunately solr has no concept of authentication and the proper proxying is not straightforward to set up and I never have the extra 2 hours in life to do that...
"Fixed" now.
No worries. I'll see if I can delete my comment above to try and avoid the issue.
Has anyone found a workaround/fix to this?
as qweqwe123 pointed out ./gradlew check was successful, but ./gradlew web -q --info still seems to be stuck at 83%
EDIT:
I should have been a bit more elaborate to start with, my apologies.
I got to do a few more experimentsnsince I first posted this question, so here is a more complete picture of what I encountered:
- ./gradlew check ran fine, resulting in BUILD_SUCCESSFUL
- ./gradlew web -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug ran without any errors too
- but, when I run ./gradlew web -q --info, the message 'Building 83% > :web' stays at the bottom of my terminal. It doesnt seem to proceed further (making me believe the build was not complete somehow), but I noticed that I was still able to ask qustions through the web UI and yodaQA returned 'some' answers to my question.
This is leaving me very confused. I do not have issues with ipv6, no proxies, running with debug enabled did not cause issues(so it shouldve got all dependencies), check was fine, it produces some answers too-but it keeps saying 'Building 83% > :web' when I run with the --info option
I had a similar issue after trying to run YodaQA inside docker. Building a container using the Dockerfile at the project root with an added last line of CMD [ "./gradlew", "web", "-q" ] causes the running yodaqa process in the docker container to fail after asking a question; DKPro attempts to download a library and will error out.
The odd thing was that on certain questions, this bug did not occur, and when I was running Yoda locally on my Mac I didn't observe the behavior - only when inside Docker.
I've found that the underlying reason was multiple threads attempting to download an NLP model jar file simultaneously and overwriting some ivy xml files in the ~/.ivy2 cache folder.
I was able to get it to work after disabling multithreading by commenting out line 42 of YodaQA_Web.java:
//ParallelEngineFactory.registerFactory(); // comment out for a linear single-thread flow
Thank you @pasky for this amazing software!! I'm currently trying to adapt Yoda to only query a custom knowledge graph (w/o freebase).
I strongly recommend adding model dependencies into the pom for production systems and even disabling auto-download entirely (set system property dkpro.model.repository.offline to true) - that ensures that you know exactly what the system can do and cannot do (i.e. use languages you didn't consider).
Sorry for my ignorance, but to be clear:
Are you talking about modifying the build.gradle file so that all the transitive dependencies of libraries in line 117 to 129:
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.api.io-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.clearnlp-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.languagetool-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.maltparser-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.opennlp-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.tokit-asl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.berkeleyparser-gpl:$dkproVersion"
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.matetools-gpl:$dkproVersion"
compile("de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.stanfordnlp-gpl:$dkproVersion") {
exclude group: "com.io7m.xom", module: "xom" // this dependency breaks XMI serialization by using utf16, c.f. UIMA-3818
}
compile "de.tudarmstadt.ukp.dkpro.core:de.tudarmstadt.ukp.dkpro.core.api.parameter-asl:$dkproVersion"
are added as well? Like for example, adding compile group: 'edu.stanford.nlp', name: 'stanford-corenlp', version: '3.6.0' to the dependencies for Stanford NLP model?
And as for setting the system property to true, does that mean executing a command of ./gradlew web -q -Ddkpro.model.repository.offline=true instead?
My comment was from the perspective of DKPro Core itself, not from the perspective of yodaqa or gradle. I am not very familiar with gradle.
Looking at the list of dependencies you posted above, it seems as if there are no dependencies on the models that are required by all of these components, e.g. MaltParser, BerkeleyParser, etc. So if there are no explicit dependencies then instead of gradle downloading the models at compile time, the DKPro Core components will try to download the models at runtime. For a production system, I would recommend downloading the models at compile-time and disabling auto-download at runtime. There is a guide here about how to add models in a Maven POM - I am not sure how that translates to Gradle.
I see; I'll look into it and see if downloading the models at compile time + using the system property that disables downloading resources at runtime also resolves the issue. Thank you!
Is anybody still having similar issue?
We are having same issue and gradle script is stuck at 83%
command
gradlew.bat web -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug
Output
A:\yodaqa>gradlew.bat web -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug
:generateTypeSystem UP-TO-DATE
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:web
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/rajan/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-simple/1.7.7/8095d0b9f7e0a9cd79a663c740e0f8fb31d0e2c8/slf4j-simple-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/rajan/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.7/58f588119ffd1702c77ccab6acb54bfb41bed8bd/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
== Spark has ignited ...
INFO Server - jetty-9.0.2.v20130417>> Listening on 0.0.0.0:4567
INFO ServerConnector - Started ServerConnector@13e98e7e{HTTP/1.1}{0.0.0.0:4567}
Preferring IPv6 connections
INFO Solr - Running Solr retrieval on remote mode
0
1
2
INFO BingFullPrimarySearch - Bing search is disabled!
INFO BingFullPrimarySearch - Bing search is disabled!
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest.model
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest.model
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest1.model
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest1.model
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest2.model
DEBUG AnswerScoreDecisionForest - model AnswerScoreDecisionForest2.model
Building 83% > :web
checked ipv6 connectivity with http://ipv6.whatismyv6.com/ and it looks fine.
those who progressed further, may be can provide help on how to run the system using gradle script.
any more settings we need to modify?
Tried with this command:
echo | gradlew.bat run -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug
Exception
ALERT: main seems stuck for more than 300s waiting for a job delivery.
Thread[main,5,main] - Future java.util.concurrent.FutureTask@2b4a0be0 done false canc false :: AE cz.brmlab.yodaqa.analysis.question.QuestionAnalysisAE from CAS org.apache.uima.cas.impl.CASImpl@7da324d0 (CIF cz.brmlab.yodaqa.flow.asb.MultiThreadASB$CasInFlow@7a61020a)
java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at cz.brmlab.yodaqa.provider.rdf.DBpediaTitles.queryFuzzyLookup(DBpediaTitles.java:256)
at cz.brmlab.yodaqa.provider.rdf.DBpediaTitles.query(DBpediaTitles.java:102)
at cz.brmlab.yodaqa.analysis.question.CluesToConcepts.process(CluesToConcepts.java:104)
at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:309)
at cz.brmlab.yodaqa.flow.asb.MultiprocessingAnalysisEngine_MultiplierOk.processAndOutputNewCASes(MultiprocessingAnalysisEngine_MultiplierOk.java:218)
at cz.brmlab.yodaqa.flow.asb.MultiThreadASB$AggregateCasIterator$1.call(MultiThreadASB.java:772)
at cz.brmlab.yodaqa.flow.asb.MultiThreadASB$AggregateCasIterator$1.call(MultiThreadASB.java:754)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
Then progress stopped at 83%. Will continue to look more into this.
Can anybody help how to fix this?
./gradlew check stuck at 83 %. Kindly help me to resolve this.
cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED
Building 83% > :test
@brojokm If you have read all the things that are above, and haven't found your solution, please try both of the following:
./gradlew check --debug If there is a problem with the build process, it should come up here.
Or
./gradlew check -Dorg.slf4j.simpleLogger.log.cz.brmlab.yodaqa=debug If there is a problem with the bootstrapping of the app, then it should be logged by this. If you can show us the logs, we may be able to provide more help.
@nagygergo after running ./gradlew check --debug it is showing
16:20:37.433 [DEBUG] [TestEventLogger] cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED
16:20:37.463 [DEBUG] [TestEventLogger]
16:20:37.463 [DEBUG] [TestEventLogger] cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STANDARD_ERROR
16:20:37.463 [DEBUG] [TestEventLogger] SLF4J: Class path contains multiple SLF4J bindings.
16:20:37.465 [DEBUG] [TestEventLogger] SLF4J: Found binding in [jar:file:/home/brojo/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-simple/1.7.7/8095d0b9f7e0a9cd79a663c740e0f8fb31d0e2c8/slf4j-simple-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
16:20:37.465 [DEBUG] [TestEventLogger] SLF4J: Found binding in [jar:file:/home/brojo/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.7/58f588119ffd1702c77ccab6acb54bfb41bed8bd/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
16:20:37.466 [DEBUG] [TestEventLogger] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
16:20:37.466 [DEBUG] [TestEventLogger] SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
16:21:14.6 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] Abort requested. Destroying process: Gradle Test Executor 1.
Building 83% > :test
@brojokm I see. This seems to be an issue with the DBPedia server being down, so the test suite is failing. In the Getting Started guide check is mainly used to download various resources, and by the time the process halts, it has already done that.
You can move on in the Getting started guide with running queries (but since at the time of writing this reply the DBPedia labels service is down, you won't be able to complete a query it unless you set up you own data backends).
You can find how to do that here
and [here] (https://github.com/brmson/yodaqa/tree/master/data/setup).
Also replace the URL-s in conf/backendURLs.json.
Notice: The disk space and computational cost of running all the data backends alongside yodaQA is a bit beyond what common user hardware (eg. a laptop) can do. You can find more about what hardware others were using.