search

mff-uk / odcs

ODCleanStore
1 stars 11 forks source link

ARES TEST - NullPointerException when iterating over inputs to XSLT #985

Closed tomas-knap closed 10 years ago

tomas-knap commented 10 years ago

Pipeline failed on DPU 'XSLT OR' because of the exception

Stack trace: java.lang.NullPointerException null at virtuoso.sesame2.driver.VirtuosoRepositoryConnection$CloseableIterationBase.moveForward(Unknown Source) at virtuoso.sesame2.driver.VirtuosoRepositoryConnection$CloseableIterationBase.hasNext(Unknown Source) at info.aduna.iteration.IterationWrapper.hasNext(IterationWrapper.java:68) at cz.cuni.mff.xrg.odcs.rdf.impl.MyTupleQueryResult.hasNext(MyTupleQueryResult.java:57) at cz.cuni.mff.xrg.intlib.extractor.simplexslt.SimpleXSLT.execute(SimpleXSLT.java:311) at cz.cuni.mff.xrg.odcs.backend.execution.dpu.Executor.executeInstance(Executor.java:226) at cz.cuni.mff.xrg.odcs.backend.execution.dpu.Executor.execute(Executor.java:354) at cz.cuni.mff.xrg.odcs.backend.execution.dpu.Executor.run(Executor.java:433) at java.lang.Thread.run(Thread.java:724)

tomas-knap commented 10 years ago

ODCS test

tomas-knap commented 10 years ago

@tomesj Jirka, as I was iterating over results provided by: rdfInput.executeSelectQueryAsTuples(query), I got a null pointer exception after approx 10hours or iterating over the results. Can you please check whether there is any timout after which openRDF automatically releases the resources? Settings in Virtuoso itself should be fine.

tomesj commented 10 years ago

Your problem is the same as here:

https://taskman.eionet.europa.eu/issues/2940

It goes about SESAME bug on Linux :-)

tomesj commented 10 years ago

Virtuoso forum with same problem: http://boards.openlinksw.com/phpBB3/viewtopic.php?f=12&t=420

tomas-knap commented 10 years ago

Was able to reproduce again, again it ends after 10hours

tomas-knap commented 10 years ago

Jirko, ale ten prvni odkaz je udajne vyresen. Koukni na to prosim. Ten druhy je z roku 2009.

Jirko, pokud by ten dotaz obsahoval nejake order by, tak by slo jednoduse po tom NPE navazat nove spojeni a pokracovat. Pripadne by sis mohl napsat vlastni tridu pro iteraci (tu vlastne mas - to je ten MyTupleQUeryResult) a v ni ziskavat vysledky pres SPARQL select .... order by limit 1000 OFFSET 0, 1000, 2000 atd.

tomas-knap commented 10 years ago

Tedy ze bys tam krom metody rdfInput.executeSelectQueryAsTuples(query); mel take novou metodu rdfInput.executeOrderedSelectQueryAsTuples(query) - u tehle metody by bylo v komentari napsano, ze pro spravnou funkcionalitu vyzaduje order by v dotazu, Kdyz tam neni, tak je uzivatel blby a nebude mu to fungovat dobre. Mno a pak ti staci pracovat s tim OFFSETema sam si ziskavat vysledky po urcitych castech.

tomas-knap commented 10 years ago

Napis prosim, co si o tom myslis

tomesj commented 10 years ago

Tak jsem si první odkaz přečetl a řešení, co tam píšou je dát ten virtuso.jar z warka do tomcatu...Což my asi nechceme...

Jinak k návrhu. Určitě by šlo se nad daty postupně dotazovat přes offset, to je asi v pohodě. Jen nechápu význam toho, proč by měl ten dotaz mít nutně ORDER BY.

skodapetr commented 10 years ago

Jirka: když nemáš order by .. tak jak zajistíš, že se ti nezmění pořadí a nedáš nějaká data 2x a jiné jen jednou? Muselo by se tam uměle přidat .. ale jinak myslím, že ho také není třeba vyžadovat (viz umělé přidání)

Co se týče warka do tomcatu .. proč to pomůže, píšou tam?

tomesj commented 10 years ago

Tak když používáš LIMIT a OFFSET pro nějaký dotaz, tak je pořadí nějaké, ale stále stejné (za předpokladu, že se kolekce nezměnila - což je v tomhle případě pravda). Takže podmínka na ORDER BY je podle mě zbytečná.

Co se týká warka - nějak více to tam nerozebírají, tak nevím ten důvod.

tomesj commented 10 years ago

Jinak se tam píše o:

Tomcat throws NullPointerException when Virtuoso JBDC driver is stored in tomcat/common/lib folder. virtjdbc-3.0.jar has to be moved from tomcat/common/lib to tomcat/common/endorsed. I have committed the modified context.xml to svn again to make the connection pooling work.

Update for Tomcat6:

The problem originates in the use of connection pools in context.xml and the use of either tomcat-dbcp or commons-dbcp. If Tomcat is installed with one of them, then it can find the driver in WEB-INF/lib. If it installed with the other, then it looks only in tomcat/lib. If you have this problem, then the easiest solution is to put virtjdbc-4.x.jar in tomcat/lib, and remove it from the cr.war:

zip -d target/cr.war WEB-INF/lib/virtjdbc-4.x.jar

skodapetr commented 10 years ago

No stejně bych tam měl radši ORDER by .. neb s tou kolekcí nikdy nevíš. Nebo mít metodu jenž bude save, a unsave .. (v tomhle ohledu) neb co když to poběží nad nějakými "měncími se" "big daty"

skodapetr commented 10 years ago

Nicméně nás se týká tomcat 7 ne? (nebo už jsem zapomněl pod čím jsme?

ad. vyzkoušet by se to mohlo ne? A pokud to pomůže, můžeme hledat proč .. ale z toho popisu mi to nepřijde .. asi bych chtěl vidět, že to pomůže.

tomesj commented 10 years ago

Tak můžeš to zkusit :-) Jo, máme TOMCAT 7.

skodapetr commented 10 years ago

No rád bych .. ale nejsem na tom zase tak časově dobře abych to zkoušel .. (jak to tam přidávat, tak to nechávat běžet 10 hodin (i když to by byl asi ten menší problém)) .. ale pokud připravíš Warko kde to bude OK .. tak myslím, že bychom to měli být schopný otestovat.

tomesj commented 10 years ago

Já na tom časově nejsem taky dobře.

Jinak k tomu možnému přistupu, co psal Tomáš vidím zádrhel. Pokud má daný SELECT query už v sobě LIMIT či OFFSET, tak je nemůžeme použít znovu - neboť dotaz je pak nevalidní....

tomas-knap commented 10 years ago

K tomu co pisete, tu upravu Tomcatu bych neresil, nehlede na to, ze se to vztahuje k Tomcat 6.

Udelal bych tu novou metodu, to by mela byt zalezitost na par hodin maximalne. V te nove metode by proste v komentari bylo uvedeno, ze se jiz ocekava, ze query bude mit order by a nebude mit limit/offset. Pokud bude chybet order by, tak se to muze chovat divne a uzivatel si to mel precistv komentari. Pokud tam bude uz v tom query limit/offset, tak to skonci chybou pri pokusu o pridani Jirkova limit/offset. Jde o to udelat alternativu k te stavajici metode, ktera by resila ten problem, ze se to spojeni po 10h proste zavre.

Jirko, tohle nemusi byt nutne hotove ted hned, ale je treba na to myslet.

tomesj commented 10 years ago

Dobře udělám na to novou třídu - OrderTupleQueryResult a přidám tam teda tuto implementaci. Tato třída pak bude jako iterátor přes Trojice a bude návratem pro metodu rdfUnit.executeOrderedSelectQueryAsTuples(orderSelectQuery).

Je to OK ?

tomas-knap commented 10 years ago

Ano, bude tam nova trida pro vysledky (jak pises treba) a nova metoda executeOrderedSelectQueryAsTuples. S tim, ze na venek, se to bude chovat uplne stejne jako ta soucasna metoda. Tedy budu moct psat:

OrderTupleQueryResult result;

while (result.hasNext()) { ... BindingSet solution = result.next();

}

Nicmene interne bude ta implementace takova, ze si vzdy nacachujes trebas 1000 bindings a az ti dojdou, tak si nacachujes dalsich 1000. Kdyz ti spadne connection po nacachovani prvnich tisic, tak se musi pokusit vytvorit nove connection, pres ktere si nacachuje dalsich 1000.

tomesj commented 10 years ago

Přesně tak nějak to mám v plánu udělat :-)

tomesj commented 10 years ago

Tak při implementaci jsem narazil na problém

Tedy dotaz např. select ?x ?y ?z where {?x ?y ?z} ORDER BY ?x LIMIT 1000 OFFSET 10000

Už skončí chybou virtuosa SE353:

V popisu se píše: Exception:virtuoso.jdbc4.VirtuosoException: SR353: Sorted TOP clause specifies more then 11000 rows to sort. Only 10000 are allowed. Either decrease the offset and/or row count or use a scrollable cursor

Stejný problém řeší např. zde: http://boards.openlinksw.com/support/viewtopic.php?f=12&t=1363

Jedno z řešení je zvednou si limit pro počet sortovaných řádku ve virtuosu.ini, ale to nemusí být optimální.

Co tedy s tím - nějaký nápad ?

tomesj commented 10 years ago

Jinak je tu alternativní řešení:

Jak jsem zjistil tak, pořadí prvků je vždy stejné, ať se použije ORDER BY deklarace či nikoliv, tedy pokud v dotazu zakážeme navíc ORDER BY stejně jako LIMIT a OFFSET bude třída fungovat správně tak jak bychom chtěli a pro libovolně velká data :-)

tomas-knap commented 10 years ago

Jirko, jakym zpusobem si dospel k tomu, ze virtuoso ta solutions bez order by vraci porad ve stejnem poradi? To nekde pisou? Kde?

Btw. ve virtuoso.ini si muzes zvednout ten limit 10000 pro order by - viz MaxSortedTopRows = 10000, http://docs.openlinksw.com/virtuoso/dbadm.html

tomas-knap commented 10 years ago
  1. ZKus prosim zvednout ten limit ve virtuoso.ini a udelej to pres to order by
  2. select ?x ?y ?z where {?x ?y ?z} ORDER BY ?x LIMIT 1000 OFFSET 10000 ti nestaci, je treba to sortovat dle vsech sloupcu.
tomesj commented 10 years ago
  1. Já nemám problém s tím zvednout si u sebe limit ve virtuosu.ini , jen pak když se to bude někde používát, tak si to musíš nastavit hlavně tam (u sebe) - aby to třeba neběželo a nevyhodila se pak výjimka výjimka díky tomu.

Pro jistotu to napíšu i do komentáře, že je důležité nastavit tuto hodnotu do virtuoso.ini - jinak nelze zaručit, že ti to bude fungovat dobře.

  1. to byl jen příklad - zadání dotazu je na uživateli - bude tam napsané co má a nemá používat. Když to použije nesprávně, je to jen jeho problém.
  2. To, že se výsledky vrací ve stejném pořadí jsem si ověřil - zkusil jsem na několika nezávislých select dotazech a různě velkých datech a zatím jsem se nepřesvědčil o opaku, tedy že by pořadí nebylo zachováno.

Ty když máš nějaký select dotaz (ne nutně s ORDER BY), který jako výsledek vrací nějakou n-tici prvků (a ten výsledek má nějaké pořadí, ne nutně seřazené) a ty ten výsledek jen rozsekáš po částech o daném počtu n-tic (stejný dotaz obohacený o LIMIT a OFFSET) a ty části postupně bereš a něco s nimi děláš

Spíš by mě přesvědčil nějaký protipříklad, že tomu tak není.

Mě osobně je to asi jedno, co z toho nakonec použijeme - klidně tam nechám tu možnost s ORDER BY, s tím, že se dodrží to, co je popsáno v [1].

Já jen hledal nějakou možnou alternativu, kterou bychom mohli zvážit :-)

tomas-knap commented 10 years ago

Jirko,

"Ty když máš nějaký select dotaz (ne nutně s ORDER BY), který jako výsledek vrací nějakou n-tici prvků (a ten výsledek má nějaké pořadí, ne nutně seřazené) a ty ten výsledek jen rozsekáš po částech o daném počtu n-tic (stejný dotaz obohacený o LIMIT a OFFSET) a ty části postupně bereš a něco s nimi děláš"

Mno, tam je problem, ze kazdy Select s prislusnym limit a offset je novy dotaz. Tedy kdyz to neseradis, tak obecne muzes dostat nejaka data dvakrat a nejaka vubec.

Zkus prosim zvednout ten limit a take poznamenej do komentare. Zkus to na vetsich datech, trebas na tech 7 milionech triples.

tomesj commented 10 years ago

Dobře...Udělám to tak a pak napíšu, jestli je to OK.

tomesj commented 10 years ago

Tak všechno je to v pohodě :-) Jen samozřejmě se stoupajícím offsetem je narůstá čas dotazu, ale s tím se asi nic neudělá :-)

tomas-knap commented 10 years ago

Ok, diky

2013/12/29 Jiří Tomeš notifications@github.com

Tak všechno je to v pohodě :-) Jen samozřejmě se stoupajícím offsetem je narůstá čas dotazu, ale s tím se asi nic neudělá :-)

Reply to this email directly or view it on GitHubhttps://github.com/mff-uk/ODCS/issues/985#issuecomment-31318613 .

tomas-knap commented 10 years ago

Zda se ze funguje a asi je to i rychlejsi nez ten puvodni tupleQueryResult.