Hi Alberto,
thanks for your fast reply.
Am 15.06.2012 12:21, schrieb [email protected]:
Hi Melanie,
thanks for reporting this issue!
I have a question, what it means:'I noticed that loading of ontologies did
not really work'?
Can you post the sequence of actions (even as curl commands) that you used
in order I can replicate the issue? Right now I tryed to store and get an
ontology to and from my Stanbol installation and everything worked
properly.
I used
curl -i -X PUT
"http://<myserver>/ontonet/ontology/<scopeID>?location=http://ontologydesignpatterns.org/ont/iks/kres/";
to create a scope and load an ontology library.
Then, to load a specific ontology into this scope, I said:
curl -i -X POST -data
"http://ontologydesignpatterns.org/ont/iks/kres/omv.owl";
http://<myserver>/ontonet/ontology/<scopeID>
That gave me some Unsupported Media Type Error.
I try to open [http://lnv-89012.dfki.uni-sb.de:9001/ontonet] but there
isn't response from the server. It is correct that uri?
The server can only be accessed from within our network, because it is
still kind of a development or test version. Sorry that the link got
into that email in the first place, I wanted to post only
'http://<myserver>/ontonet#', with the placeholder instead of the URL.
Best, Melanie
Bests,
Alberto Musetti
correction: The same exception message is also written to the log file
when requesting other webpages of the Stanbol REST API like e.g. the
contenthub, just only a very few times so that the page is loaded with
no perceivable delay.
This means that while trying out the curl commands on the ontonet's REST
API on Tuesday, I must have blown my stanbol installation.
Has anyone ever (successfully) worked with the instructions from that
page?
Sebastian recommended to simply re-install, and maybe that will solve
the problem; but if I again use the same commands I might destroy the
stanbol over again. So do you have a reference for the ontonet endpoint
apart from the README file and the http://<myserver>/ontonet#
<http://lnv-89012.dfki.uni-sb.de:9001/ontonet#> ? (e.g. for creating
scopes, loading ontologies and the like)
Am 15.06.2012 10:50, schrieb Melanie Reiplinger:
I forgot to mention: loading of the page does not fail, however. After
several minutes, and after writing 2-3G of exception messages into the
logfile, the page appears in the browser.
Am 15.06.2012 10:42, schrieb Melanie Reiplinger:
Hi Stanbolers, Hi Rupert.
I started working on the ontonet endpoint (in order to implement the
Javascript interface) this week. First, I noticed that loading of
ontologies did not really work. Second, the stanbol server got
terribly slow as soon as I had started posting requests to the
ontonet/ontology. (curl commands took several minutes, loading a page
into the browser up 5-10 minutes). Meanwhile, loading the other
endpoints was unproblematic as usual. Then my network group notified
me that the disk space used by stanbol exploded during that time.
I checked and found that the stanbol/logs/ folder gains several G in
size while requesting e.g.
http://<myserver>/ontonet/ontology/
<http://lnv-89012.dfki.uni-sb.de:9001/ontonet/ontology/>
(i.e., while trying to load the page into the browser)
In the file error.log, there is the same exception written over and
over again:
15.06.2012 10:16:08.238 *WARN* [28346522@qtp-25994851-1 - Acceptor0
[email protected]:9001] org.apache.felix.http.jetty
EXCEPTION (java.io.IOException: Too many open files)
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163)
at
org.mortbay.jetty.nio.SelectChannelConnector$1.acceptChannel(SelectChannelConnector.java:75)
at
org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:664)
at
org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:191)
at
org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at
org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Do you know this problem?
