Hi David, I'm running jetty as per the instructions in github- so mvn jetty:run-war. I'll see what I can do about reproducing the problem and getting log files to you- although this will now have to wait till tomorrow (it's home time here!).
I have confused the issue with spaces in layer names- it's not the layer names that have spaces, it's the data stores. Roughly speaking, I can see a 404 error appearing when it's trying to find the REST URL for the coverage store and it's stopping at the space. Thanks for your prompt responses! Jo ----- Original Message ----- From: "David Winslow" <[email protected]> To: [email protected] Sent: Wednesday, 22 September, 2010 4:40:54 PM Subject: Re: [geonode] Questions How are you loading jetty when you run it independently of paster? GeoNetwork runs afoul of a pretty nasty JVM bug which causes (as far as I can tell) unbounded CPU and memory consumption. 'paster host' and the startup.sh script avoid this by passing some extra options to the JVM hosting Jetty, but if you just use "mvn jetty:run" then you'll have the issue. Other than that, I'll admit we haven't pushed GeoNode very hard in terms of massive datasets; the biggest updatelayers job I've personally run has been on demo.geonode.org which only has ~120 layers. We are definitely interested in having such imports run smoothly, so I'd be interested in seeing those log files. When running via "paver host" the jetty and paster output end up in .log files in the root directory of the geonode build. When running otherwise, you're on your own. A useful trick for dumping these files is the 'tee' command which dumps text to a file while also displaying it to the console so you aren't flying blind. If you are running via startup.sh then using tee would look like: $ sh startup.sh 2>&1 | tee jetty.log Ideally (for me :) you would find a quick way to reproduce the memory problem and reproduce the issue immediately after starting the server to reduce unrelated messages in the log file. In regards to layers with spaces in the names... I guess you are getting these issues in gsconfig.py? The geoserver catalog and the django backend should both handle spaces fine. However, layer names with spaces can cause problems in several places; for example, WFS responses will come back with invalid XML because the layer name is used as an XML prefix. Please provide a stack trace of this as well, but in general layer names should not contain spaces or other characters that are not valid as part of an XML tag name. -- David Winslow OpenGeo - http://opengeo.org/ On Wed, Sep 22, 2010 at 11:06 AM, Joanne Cook < [email protected] > wrote: Hi David, Many thanks. I think I have this working, but only if I load jetty and paster separately. I'm still trying to track down why running paver host doesn't work. However, I have hit a big gotcha in that a lot of my data stores in my main geoserver installation have spaces in their names, and this is causing geonode to fail when I update the layers. On a slightly separate issue, when I run jetty and paster separately, I encounter some out of memory errors when loading data into geonode (this is from before I configured it to work with a remote geoserver instance). I have changed the settings for jetty, but these still occur. However, when I call them together using paver host, I don't get the out of memory errors. Unfortunately, if the jetty load times out because it has a lot of updates to do, then this causes errors- and also I have the problem noted above when running it in this way... I'm happy to provide more information on these things if you can tell me which logs you need and where to find them. Thanks Jo ----- Original Message ----- From: "David Winslow" < [email protected] > To: [email protected] Sent: Tuesday, 21 September, 2010 2:07:02 PM Subject: Re: [geonode] Questions The paster/Django portion of GeoNode communicates with GeoServer exclusively over HTTP. So jetty must be running when you run the django-admin.py command. Additionally, the Django application must be running in order to provide GeoServer without authentication information. (That is, both paster and jetty must be running when you use the admin command.) The updatelayers command only imports layers, it does not remove existing ones, so your existing test layers will not be overwritten. -- David Winslow OpenGeo - http://opengeo.org/ On Tue, Sep 21, 2010 at 6:15 AM, Joanne Cook < [email protected] > wrote: Thanks David, So to confirm I have understood this correctly- I would change GEOSERVER_BASE_URL in src/geonode/settings.py, run the django-admin.py command as below, then start geonode without jetty, using paster serve --reload shared/dev-paste.ini? Would this overwrite existing test layers that I have loaded into geonode (I am quite happy for it to do that)? Jo ----- Original Message ----- From: "David Winslow" < [email protected] > To: [email protected] Sent: Monday, 20 September, 2010 5:29:22 PM Subject: Re: [geonode] Questions Once GeoNode is installed, the update script is integrated into the Django administration tool. You can invoke it like so: $ django-admin.py updatelayers --settings=geonode.settings Currently GeoNode only supports syncing with one GeoServer instance this way. Hope this helps. -- David Winslow OpenGeo - http://opengeo.org/ On Mon, Sep 20, 2010 at 12:13 PM, Joanne Cook < [email protected] > wrote: Hi All, I met some of you at FOSS4G a few weeks ago, and also attended the tutorial on SDI best practices with Geonode. In that, someone (Sebastian?) mentioned being able to connect Geonode to a remote Geoserver instance, and run a script to get Geonode up to date with the Geoserver layers. Can someone give me some more information on where I might find this script? Thanks Jo -- ----------------------------------------------------- Joanne Cook Senior IT Support and Development Oxford Archaeology (North) 01524 880212 http://thehumanjourney.net ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. -- ----------------------------------------------------- Joanne Cook Senior IT Support and Development Oxford Archaeology (North) 01524 880212 http://thehumanjourney.net ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. -- ----------------------------------------------------- Joanne Cook Senior IT Support and Development Oxford Archaeology (North) 01524 880212 http://thehumanjourney.net ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. -- ----------------------------------------------------- Joanne Cook Senior IT Support and Development Oxford Archaeology (North) 01524 880212 http://thehumanjourney.net ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
