On 13/05/16 09:45, Sorin Gheorghiu wrote:
Hi Andy,
I found on the server a coredump reporting insufficient memory for the
JRE (see attach).
It is weird, fuseki allocates a 32Gb maximum Java heap size, but it uses
only 16Gb:
#
java -Xmx32G -jar fuseki-server.jar --update
--config=/etc/default/
Hi Andy,
I found on the server a coredump reporting insufficient memory for the
JRE (see attach).
It is weird, fuseki allocates a 32Gb maximum Java heap size, but it uses
only 16Gb:
#
java -Xmx32G -jar fuseki-server.jar --update --config=/etc/default/fuseki/config.ttl
As well *ulimit -c u
Hi,
It's not clear to me what's happening. The server log may offer some
more information. It's as if the response in truncated somehow.
You could try using curl or wget to make the request. They can also
print out the HTTP headers.
Andy
On 12/05/16 19:43, Sorin Gheorghiu wrote:
Hi,
Hi,
the attempt to perform a sparql insert using *s-update* has failed with
the error:
# /opt/apache-jena-fuseki-2.3.1/bin/s-update
--service=http://localhost:3030//update --file update.ru
/usr/lib/ruby/1.9.1/net/protocol.rb:141:in `read_nonblock': end of file
reached (EOFError)
f
Hi there,
This looks like something to do with the solr setup. I'm not very
familiar with solr, is there some configuration that affects timeouts on
connections? I don't think Jena does any timeouts itself.
Andy
On 03/05/16 08:50, Sorin Gheorghiu wrote:
After Solr server restart, it lo
After Solr server restart, it looks like the indexes aren't corrupted.
Thus, it seems the error isn't critical and I may ignore it.
But my expectation was that the insert command will add the new
parameter to Jena TDB and not to Solr.
Weitergeleitete Nachricht
Betreff:
