ELDA: No properties returned for ListEndpoint with more than x results.

[Nic Gould]

I'm seeing some strange behaviour in ELDA (latest version), where for a ListEndpoint if I return more than a certain number of results, no properties are returned for any of the items. If I reduce the result count down to a certain value then i correctly see all properties for each item, and can scroll through multiple pages of results no problem. I can run the query against my sparql endpoint (blazegraph) directly and the correct data is being returned.

Am I missing something or is this a bug?

Any help or suggestions gratefully received!

[chris dollin]

Sounds suspiciously buglike.

What is the "certain number of results"?

Which format are you using? What happens if you try
a different format?

Can you provide a minimal complete example?

Chris

> --
> You received this message because you are subscribed to the Google Groups
> "linked-data-api-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linked-data-api-d...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Chris "allusive" Dollin

[Stuart Williams]

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hello Nic,

One of the things that I do when faced with a problem like this is to try to determine whether elda has assemble the correct data or whether its failing to correctly render the data that it's collected - I assume that your comments are in relation to the html pages that you're rendering (are you using the xslt or velocity render?).

The quick check that I do is to look at the .ttl and .json renderings to see if elda is returning what I'd expect. Certainly if the data is missing from the .ttl response and bare use of the 'view query' at a SPARQL endpoint returns the expected result - something has gone awry.

A second check that I make, particularly for an ordered output, is to use a smaller page size and step through the pages. I have found occasions where one item in a large response has something in it (eg. an illegal URI) that cause elda to throw the whole response - finding that one item and understanding what's wrong with it can sometimes unlock a proble. IIRC elda is not very tolerant of badly formed URI in data (the log files around a failure may also contain more info).

If the problem is only happening for an HTML page check the page source to see if you are receiving a whole page - are the tags properly nested and is there a </html> at the end? If not then something is probably broken in the renderer (or a customisation of the renderer).

Another possibility, especially with a large response, is that elda hasn't been given enough heap to hold the response graph.

You can turn on debug logging by changing the log-level in log4j.properties in the directory that the elda webapp is unpacked into.

Just a few thoughts.

HTH

Stuart

-- 
Epimorphics Ltd                        www.epimorphics.com 
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

[Nic Gould]

Hi Chris & Stuart, thanks for getting back to me.

I can confirm that the ttl and json renderings also suffer from exactly the same problem as the html, but that sending the query directly to the sparql endpoint returns the expected results. The number of results that can be displayed before the issue becomes apparent seems to depend on the viewer that is being used (12 with a larger custom viewer and 26 with with the basic viewer).

It looks like it could be connected to the number of triples being returned, with up to about 125 being fine but 130 or more resulting in no properties for any items. This seems more likely than a bad uri or similar as you can use the _page parameter to offset the results and the same behaviour is observed.

Chris, I don't have this a self-contained example at present. But will see if I can get chance to produce one for you at some point.

On Thursday, 18 February 2016 13:38:55 UTC, skw wrote:

On 2016-02-18 12:35, Nic Gould wrote:

I'm seeing some strange behaviour in ELDA (latest version), where for a ListEndpoint if I return more than a certain number of results, no properties are returned for any of the items. If I reduce the result count down to a certain value then i correctly see all properties for each item, and can scroll through multiple pages of results no problem. I can run the query against my sparql endpoint (blazegraph) directly and the correct data is being returned.

Am I missing something or is this a bug?

Any help or suggestions gratefully received!

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stuart Williams]

Hello Nic,

On 2016-02-18 14:28, Nic Gould wrote:

Hi Chris & Stuart, thanks for getting back to me.

I can confirm that the ttl and json renderings also suffer from exactly the same problem as the html, but that sending the query directly to the sparql endpoint returns the expected results. The number of results that can be displayed before the issue becomes apparent seems to depend on the viewer that is being used (12 with a larger custom viewer and 26 with with the basic viewer).

It looks like it could be connected to the number of triples being returned, with up to about 125 being fine but 130 or more resulting in no properties for any items. This seems more likely than a bad uri or similar as you can use the _page parameter to offset the results and the same behaviour is observed.

Those seem like *very* small numbers of triples!

What heaps size are you using? What webapp container?

Stuart
--

To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nic Gould]

Yes it's just a local demo running on a VM on my laptop. So using elda-standalone-1.3.17 with default heap sizes, VM has 8GB of RAM.

[Stuart Williams]

On 2016-02-18 14:46, Nic Gould wrote:

Yes it's just a local demo running on a VM on my laptop. So using elda-standalone-1.3.17 with default heap sizes, VM has 8GB of RAM.

Hmmm.... I don't know what the defaults are for the enviroment you are running in, but I usually find them to small. I'd recommend at least 1Gbyte of heap (-Xmx1G). Also, if your data is deeply nested you might need to increase the thread stack size (-Xss10M)

Stuart
--

To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-d...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nic Gould]

Same result I'm afraid, both with 2G heap and 10M thread stack. I'll look at reproducing with a cutdown dataset so that I can send you to reproduce - may not be till next week though as I'm away Fri-Tuesday

On Thursday, 18 February 2016 15:12:41 UTC, skw wrote:

On 2016-02-18 14:46, Nic Gould wrote:

Yes it's just a local demo running on a VM on my laptop. So using elda-standalone-1.3.17 with default heap sizes, VM has 8GB of RAM.

Hmmm.... I don't know what the defaults are for the enviroment you are running in, but I usually find them to small. I'd recommend at least 1Gbyte of heap (-Xmx1G). Also, if your data is deeply nested you might need to increase the thread stack size (-Xss10M)

Stuart
--

On Thursday, 18 February 2016 14:34:17 UTC, skw wrote:

Hello Nic,

On 2016-02-18 14:28, Nic Gould wrote:

Hi Chris & Stuart, thanks for getting back to me.

I can confirm that the ttl and json renderings also suffer from exactly the same problem as the html, but that sending the query directly to the sparql endpoint returns the expected results. The number of results that can be displayed before the issue becomes apparent seems to depend on the viewer that is being used (12 with a larger custom viewer and 26 with with the basic viewer).

It looks like it could be connected to the number of triples being returned, with up to about 125 being fine but 130 or more resulting in no properties for any items. This seems more likely than a bad uri or similar as you can use the _page parameter to offset the results and the same behaviour is observed.

Those seem like *very* small numbers of triples!

What heaps size are you using? What webapp container?

Stuart
--

Chris, I don't have this a self-contained example at present. But will see if I can get chance to produce one for you at some point.

On Thursday, 18 February 2016 13:38:55 UTC, skw wrote:

On 2016-02-18 12:35, Nic Gould wrote:

I'm seeing some strange behaviour in ELDA (latest version), where for a ListEndpoint if I return more than a certain number of results, no properties are returned for any of the items. If I reduce the result count down to a certain value then i correctly see all properties for each item, and can scroll through multiple pages of results no problem. I can run the query against my sparql endpoint (blazegraph) directly and the correct data is being returned.

Am I missing something or is this a bug?

Any help or suggestions gratefully received!

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-discuss+unsubscr...@googlegroups.com.