Menu
▾
▴
Re: [Bigdata-developers] using nanoSparqlServer with federation
|
From: Bryan T. <br...@sy...> - 2011-07-13 12:21:42
|
Israel, Do NOT change the root level logger to DEBUG for the cluster. Bigdata has a LOT of conditional logging. If you go to root level DEBUG it will produce a huge amount of log information, especially in the com.bigdata.btree package. The problem you are reporting should be logged out at an ERROR level by the BigdataRDFServlet (see my previous email). The default cluster configuration is designed to aggregate log messages to a node running a log4j SocketAppender. This is handled in the bigdata start/stop script and in src/resources/config/log4j.properties and log4jServer.properties. The log4jServer.properties file should be putting everything onto a single log file whose name is configured in log4jServer.properties. Generally, you want to tail that log file to observe errors. I would also suggest viewing the page source for the error page that was served up. There might be more information which is not being rendered properly. Thanks, Bryan ________________________________________ From: Isr...@th... [Isr...@th...] Sent: Wednesday, July 13, 2011 7:49 AM To: Bryan Thompson Subject: RE: using nanoSparqlServer with federation Hi Bryan, In which log should I expect to see the stack trace? I have changed the root logger level to DEBUG in the log4j.properties file, but still all the log files, except for the state.log are empty. I did not use any program, I just used the poster plug-in in Firefox to POST a URI. Thanks, Israel -----Original Message----- From: Bryan Thompson [mailto:br...@sy...] Sent: Wednesday, July 13, 2011 2:26 PM To: Klein, Israel; big...@li... Subject: RE: using nanoSparqlServer with federation Israel, If you are having difficulties getting a full stack trace, can you send a small program which exhibits the exception and I will look into it this morning. I've tracked down the code change that I was thinking of, which was to TimestampChooser, and it appears that the change there was applied to both the release and the development branch so this is something different. The BTree is the node-local mutable b+tree object. The IClientIndex is a remote view of a sharded B+Tree. I'm not sure where the class cast is coming from based on what is inline below, but if you have the rest of the stack trace or can provide a small example I will track this down. Thanks, bryan ________________________________________ From: Isr...@th... [Isr...@th...] Sent: Wednesday, July 13, 2011 6:42 AM To: big...@li... Subject: [Bigdata-developers] FW: using nanoSparqlServer with federation From: Klein, Israel Sent: Wednesday, July 13, 2011 1:39 PM To: 'big...@li...' Subject: using nanoSparqlServer with federation Hi, I have installed a federation on 9 machines using the bigdataCluster16.config example which seems to work fine (used the latest BIGDATA_RELEASE_1_0_0 branch). Then I have started a nanoSparqlServer.sh and I can access its /status and /counters URLs. However, when I try to POST a new URI I get the following exception: <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/> <title>Error 500 java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: com.bigdata.btree.BTree cannot be cast to com.bigdata.service.ndx.IClientIndex</title> </head> <body> <h2>HTTP ERROR: 500</h2> <p>Problem accessing /sparql. Reason: <pre> java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: com.bigdata.btree.BTree cannot be cast to com.bigdata.service.ndx.IClientIndex</pre></p> <hr /><i><small>Powered by Jetty://</small></i> I use http://[host]:[port]/[namespace]/sparql?uri=[a<http://[host]:[port]/%5bn amespace%5d/sparql?uri=%5ba> url which returns an RDF in n3 format] which works fine when using it on a nanoSparalServer war on a separate Tomcat. Thanks, Israel This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. |
