On 09/04/12 19:47, Rob Vesse wrote:
Hi Regis
Please see this thread where I experienced a similar issue:
https://issues.apache.org/jira/browse/JENA-181
A couple of possible solutions is either to insert delays between
queries (not possible in your scenario) or to set
-XX:MaxDirectMemorySize to a higher value than the default
Andy - is it possible that the Service code is not calling close() on
the query iterators in a timely fashion (i.e. keeping too many
connections open thus exhausting the direct memory buffer) as that
turned out to be the main culprit in my case from re-reading that thread.
It's possible but not in the simplest way because QueryIterService calls
QueryIter.materialize so it should be reading the results when the
results are first received. Looking at the code, exhausting the
iterator should call the close operation. I tried breakpointing a
single SERVICE call and it did hit the close breakpoint.
But in the server, direct memory does not always seem to be returned or
retuned fast enough. We have had to -XX:MaxDirectMemorySize (plan B:
use a separate jetty config and pick a different connector implementation).
Having two SERVICE calls means the second is called for each match from
the first.
An experiment is to put a LIMIT on the first call and see what numbers
matter.
Andy
