[Mulgara-general] RMITimeoutException

[Paul Gearon]

TQL does count in a sub-select inside the select clause. For every
solution binding it will execute the count.

I can't give you the exact query to use, since I don't know what query
you are executing. Is it in the Topaz logs?

There is some description of count on the page:
  http://mulgara.org/trac/wiki/Select
Look towards the bottom for "count Function"

For instance, to count the contents of a graph with TQL, I use something like:
  select count(select ?s ?p ?o from <graphname> where ?s ?p ?o)
  from <graphname> where ?a ?b ?c;

The second line there is not really important. It just needs to be
something that will result in *something* (meaning a non-empty
result). If it's simple like this then there won't be any processing
cycles wasted on it. (The outer query may seem strange, but it's a
structure that's very handy for more complex aggregation queries).

I haven't had time to do SPARQL 1.1 counts yet, but I don't think that
would help you anyway since you're using Topaz, which is entirely TQL.

Paul

On Fri, Apr 15, 2011 at 12:21 PM, Joe Osowski <josowski at plos.org> wrote:
> What would be the TQL to fetch the total count?
>
> On 04/15/2011 08:49 AM, Paul Gearon wrote:
>> On Fri, Apr 15, 2011 at 11:38 AM, Joe Osowski<josowski at plos.org>  wrote:
>>> I believe I found a bug in the Mulgara RMI client.
>>>
>>> The mulgara.rmi.pagetimeout system setting seems to have no affect.
>>> Note the partial stack trace (and the times they were logged).
>>>
>>> 2011-04-14 22:32:47,290 DEBUG [main] Migrator - Running Topaz Query:
>>> select c.id from UserProfile c
>>> 2011-04-14 22:33:47,384 ERROR [main] Migrate - Error querying for
>>> UserProfile ids
>>> java.lang.RuntimeException: Error querying for UserProfile ids
>>>          at
>>> org.ambraproject.service.Migrator.getObjectIDs(Migrator.java:319)
>>>          at org.am.....
>>> Caused by: org.mulgara.server.rmi.RMITimeoutException: No data returned
>>> within 1200000ms
>>>          at
>>> org.mulgara.server.rmi.RemoteAnswerWrapperAnswer.waitForPrefetchThread(RemoteAnswerWrapperAnswer.java:492)
>>>          at
>>> org.mulgara.server.rmi.RemoteAnswerWrapperAnswer.nextPage(RemoteAnswerWrapperAnswer.java:458)
>>>          at
>>> org.mulgara.server.rmi.RemoteAnswerWrapperAnswer.next(RemoteAnswerWrapperAnswer.java:427)
>>>          ... 7 more
>>>
>>> I wonder if there is a way to easily get the total count of records and
>>> then return paged results using ordering, offset and limit.  Would this
>>> be faster?
>> Total record counts are available internally, so I guess it's possible
>> to get that. However, the time that you're waiting is due to ordering
>> that occurs for the "distinct" result. Topaz can use NONDISTINCT now,
>> but you probably don't have that option.
>>
>> The other thing I was thinking of was an optimization to make DISTINCT
>> go faster. This involves using a Set for results that gets backed by
>> disk storage. This could start returning data immediately, and would
>> be much faster than a sort anyway. I'd need some time to get it
>> implemented and released though (I'm really busy this weekend).
>>
>> Paul
>