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 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? 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? >>> >> > >
