Well unfortunately we are not there yet, we are having to re-engineer quite a lot of things around the re-design of our query.
In the meantime we have tried to roll-back and are considering increasing the stack size as Andy suggested. However, my fear is that this will not actually help us at all. Although it was not clear in my original email, because I cut out some of the stacktrace to save bytes, my reasoning is thus: Our query contains 9,669 unions, however in the stack trace we see 270,000+ frames which are mostly the following repeating over and over again: at com.hp.hpl.jena.sparql.algebra.op.OpUnion.visit(OpUnion.java:49) at com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit2(OpWalker.java:102) at com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:74) as there is such a disparity between the number of unions we actually want to perform and the number of stack frames for OpUnion, I am rather inclined to believe at the moment that this is a recursion bug. My concern is that no matter how large I grow the stack size, it will continue to overflow. Would that be a correct assumption? ...or is it correct that I should have 270,000+ OpUnion frames for a union of just 9,669 resources? Thanks On 17 March 2014 20:55, Andy Seaborne <a...@apache.org> wrote: > On 17/03/14 18:17, Adam Retter wrote: >> >> Thanks Guys, >> >> >> We did try using the: >> >> "yourSPARQLEndpoint elda:supportsNestedSelects true." >> >> Although I think we found that the option was actually (non-plural): >> >> "yourSPARQLEndpoint elda:supportsNestedSelect true." >> >> However, whilst Elda reported that it did indeed support the >> NestedSelect, it continued to create that absolutely massive union for >> our query. > > > Bizarre - probably one for the ELDA mailing list > linked-data-api-discuss AT googlegroups.com > > >> >> The good news is my colleague Rob was able to change Elda's config >> file so that it generated a much simpler query for us. So we have now >> moved past that one. If anyone wants more info on this, please say, >> and I will ask him to post some detail. > > > Yes - it would be interesting to know what changes you made, and their > effect. > > Andy > > >> >> Thanks for all your help guys. >> >> >> >> On 17 March 2014 06:51, Chris_Dollin <ehog.he...@gmail.com> wrote: >>> >>> On Sunday, March 16, 2014 06:58:29 PM Adam Retter wrote: >>> >>>> Unfortunately, today, we have a query that is generated by Elda and >>>> POST'ed to Fuseki (https://github.com/epimorphics/elda). The query is >>>> about 1.4MB! >>>> >>>> Unfortunately this query causes Fuseki to throw a >>>> java.lang.StackOverflowError. The only other post I found on the >>>> mailing list which looks similar was from 2011 >>>> http://markmail.org/message/pwzdrcn7lnkqra35 but there was no follow >>>> up to it. >>> >>> >>> Concur with Andy -- you need to enable the nested select option >>> (which has been in Elda for a long time, since we hit exactly the same >>> issue of ENORMOUS queries you have ...) >>> >>> Add to your configuration: >>> >>> yourSPARQLEndpoint elda:supportsNestedSelects true. >>> >>> where elda has been defined with >>> >>> @prefix elda: >>> <http://www.epimorphics.com/vocabularies/lda#> . >>> >>> This is documented at >>> >>> >>> http://epimorphics.github.io/elda/docs/E1.2.29/reference.html#section-1015 >>> >>> (which is the .29 documentation, but this aspect hasn't changed since it >>> was >>> introduced, and I see a couple of typos there which I will fix before .30 >>> comes >>> out Later This Week All Being Well.) >>> >>> Chris >>> >>> >>> >> >> >> > -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
