Blog
what did i learn today
News geoserver oracle
[geoserver] failed to look up primary key in oracle table

I have a very weird problem with my geoserver+oracle, when deployed on a Windows 2012R2 server (see here), and in attempting to solve that, I upgraded the geoserver from 2.6.3 to 2.7.1, hoping that that would fix that.

Sometimes fairy tales come true, but in this case it did not help, unfortunately. The 2.7.1 did render a lot quicker, except one layer which did not render at all anymore.

My style could not render with the error The requested Style can not be used with this layer. The style specifies an attribute of <missing attribute name>. Checking the layer in geoserver, I could see it was no longer to determine any of the attributes for the given table.

Further investigation in the logfile revealed the following (cryptic) error:

Failure occurred while looking up the primary key with finder: org.geotools.jdbc.HeuristicPrimaryKeyFinder@24cf7139

java.sql.SQLException: Exhausted Resultset

Mmmmmm. Luckily my google-fu revealed a linked issue, and simple solution:

update the driver from ojdbc14.jar to the newer ojdbc7.jar fixes this problem.

Hehe :)

More ...
News geoserver oracle
[geoserver] having duplicate columns in your oracle based layer

Updating geoserver did not fix my problem: my layer still had some duplicate columnnames. This might not be such a big problem: everything is drawn correctly, WMS calls work, but WFS calls gave the irritating yet predictable error ORA-00918: column ambiguously defined. Annoying.

So how does one find column-names for a table in oracle? With a query like:

select * from dba_tab_columns where table_name = 'YOUR_TABLE_NAME';

and all of a sudden I saw the same set of column-names, with some duplication. Apparently my oracle database contains the table twice, in two different schema's. Since my user had the permissions to access the other schema, it seems geoserver does not limit the query to the (specified) schema at all.

The fix then was easy: make the other schema unaccessible. In my case the second schema was for testing purposes, so I could just delete it.

More ...
Technology geoserver
tuning Geoserver on windows for production

I develop my website using a MacBook Pro retina, and deploy on windows. And I noticed that my Macbook Pro is a lot faster than the standard GeoServer install. I use Geoserver only to serve the WMS layers, vector data which is stored in postgis.

So I needed to tune GeoServer on Windows for optimal performance. I googled around, and found I needed to make the following changes:

  • make sure jvm runs in -server mode
  • make sure jvm is allocated enough memory
  • optimise jvm settings
  • install native JAI/ImageIO binaries
  • switch to production logging

I used the standard Geoserver binary install, so to tune the jvm settings, you have to edit c:\program files\Geoserver xxx\wrapper\wrapper.conf and add the following lines:

# Java Additional Parameters
wrapper.java.additional.1=-Djetty.home=.
wrapper.java.additional.2=-DGEOSERVER_DATA_DIR="%GEOSERVER_DATA_DIR%"
wrapper.java.additional.3=-server 
wrapper.java.additional.4=-Xmx2048M -Xms2048m 
wrapper.java.additional.5=-XX:SoftRefLRUPolicyMSPerMB=36000 
wrapper.java.additional.6=-XX:MaxPermSize=128m 
wrapper.java.additional.7=-XX:NewRatio=2

to be able to run the jvm in server mode, I had to copy $JAVA_HOME\bin\client to $JAVA_HOME\bin\server which feels like an awesome hack.

But Geoserver does seem a lot quicker.

I read the wms shootout benchmarks (2011) and one of the results showed that MapServer was a lot quicker on linux (vs. windows).

So that has got me wondering though, what possible other things I could do to improve performance.

E.g.

  • deploy geoserver on linux vs windows?
  • switch containers: jetty vs tomcat vs jboss, or doesn't that make much of a difference?
  • or how hard would it be to switch to a "quicker" wms, e.g. mapnik/mapserver

So since none of this questions I can find answered somewhere on the web (at least not easily, and i asked), I will probably be doing some benchmarks for myself soon.

More ...