./gradlew check hanging about yodaqa HOT 35 OPEN

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.

from yodaqa.

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

from yodaqa.

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.

from yodaqa.

Please let me know if there's anything new. Even if you've solved this, too!

from yodaqa.

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?

from yodaqa.

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.

from yodaqa.

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.]

from yodaqa.

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? 😁

from yodaqa.

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.

from yodaqa.

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

from yodaqa.

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.)

from yodaqa.

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?

from yodaqa.

from yodaqa.

cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED

Building 83% > :test

Same here. So, is it a proxy issue? or bug?

from yodaqa.

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?

from yodaqa.

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).

from yodaqa.

from yodaqa.

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.

from yodaqa.

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).

from yodaqa.

Repo is back online: http://zoidberg.ukp.informatik.tu-darmstadt.de/artifactory/public-model-releases-local/de/tudarmstadt/ukp/dkpro/core/de.tudarmstadt.ukp.dkpro.core.opennlp-model-sentence-en-maxent/

from yodaqa.

Works. Amazing, thank you so much.

from yodaqa.

No worries. I'll see if I can delete my comment above to try and avoid the issue.

from yodaqa.

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

from yodaqa.

from yodaqa.

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).

from yodaqa.

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).

from yodaqa.

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?

from yodaqa.

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.

from yodaqa.

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!

from yodaqa.

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?

from yodaqa.

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?

from yodaqa.

./gradlew check stuck at 83 %. Kindly help me to resolve this.

cz.brmlab.yodaqa.provider.rdf.DBpediaTypesTest > testQueryTitleForm STARTED

Building 83% > :test

from yodaqa.

@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.

from yodaqa.

@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

from yodaqa.

@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.

from yodaqa.