Hi Jacob,
Sorry if I just do not remember, but did you have any success with Oracle without using your existing data directory? I have been using Geoserver with Oracle for about 10 years and I still do things in this order when I test new versions before upgrading:
-
Install new Geoserver with default installer and default data_dir, check that it works
-
Add Oracle driver to the play, check with demo data adding Oracle driver did not break anything
-
Try to create a new Oracle store and one layer, check if I works
-
Switch to use the existing data_dir instead of the demo one, test
For example, if there is something wrong with the Oracle driver and I use our production data_dir I will receive tons of errors into the log. But if I try to add a new Oracle store and layer and if fails I am getting much less log and it is easier to filter out the meaningful part of it. You said you have hundreds of Oracle layers configured, it would be interesting to know if you can start your server with 1 layer, 10 layers, 50 layers or 100 layers.
-Jukka Rahkonen-
Jacob Overgaard Madsen wrote:
···
Hi guys
To take the Weblogic and Jetty out of the equation - in my quest for a working Geoserver 2.8.0 - I now tried setting up a test instance of the latest Tomcat 7 with Geoserver, using my existing data directory on Windows x64, using the Windows service installer version of Tomcat. I did this, because as far as I understand, Tomcat is the server you mostly support. I simply had to try something to progress in this. Then I could eventually try convincing my boss of letting me set up a Tomcat server later.
However, this also seems to get me nowhere. I have set the GEOSERVER_DATA_DIR environment variable to the right data directory. I have also set CATALINA_OPTS to
-Xms512M -Xmx1024M -XX:MaxPermSize=128m
according the the “Container considerations”.
Still, the server refuses to start. I again monitor the log closely during boot. The server seems to load all my Oracle data stores as expected. But I never reach a running state. It seems, that regardless of what memory options I specify in CATALINA_OPTS, the server sooner or later blows up with
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2367)
at java.lang.String.(String.java:168)
at oracle.jdbc.driver.DynamicByteArray.getStringFrom1Byte(DynamicByteArray.java:589)
at oracle.jdbc.driver.DynamicByteArray.getString(DynamicByteArray.java:447)
at oracle.jdbc.driver.CharCommonAccessor.getString(CharCommonAccessor.java:352)
at oracle.jdbc.driver.GeneratedStatement.getString(GeneratedStatement.java:327)
at oracle.jdbc.driver.GeneratedScrollableResultSet.getString(GeneratedScrollableResultSet.java:882)
at oracle.jdbc.driver.GeneratedResultSet.getString(GeneratedResultSet.java:1460)
at org.apache.commons.dbcp.DelegatingResultSet.getString(DelegatingResultSet.java:263)
at org.apache.commons.dbcp.DelegatingResultSet.getString(DelegatingResultSet.java:263)
at org.geotools.jdbc.JDBCDataStore.createTypeNames(JDBCDataStore.java:997)
at org.geotools.data.store.ContentDataStore.getTypeNames(ContentDataStore.java:308)
at org.vfny.geoserver.util.DataStoreUtils.getDataAccess(DataStoreUtils.java:96)
at org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:590)
at org.geoserver.catalog.ResourcePool.getCacheableFeatureType(ResourcePool.java:897)
at org.geoserver.catalog.ResourcePool.tryGetFeatureType(ResourcePool.java:884)
at org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:870)
at org.geoserver.catalog.ResourcePool.getFeatureType(ResourcePool.java:865)
at org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureType(FeatureTypeInfoImpl.java:120)
at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:146)
at com.sun.proxy.$Proxy11.getFeatureType(Unknown Source)
at org.geoserver.gwc.layer.CatalogConfiguration.isLayerExposable(CatalogConfiguration.java:444)
at org.geoserver.gwc.config.GWCInitializer.addLayersToNotCache(GWCInitializer.java:281)
at org.geoserver.gwc.config.GWCInitializer.initialize(GWCInitializer.java:151)
at org.geoserver.config.GeoServerLoader.loadInitializers(GeoServerLoader.java:150)
at org.geoserver.config.GeoServerLoader.postProcessBeforeInitialization(GeoServerLoader.java:130)
at org.geoserver.config.GeoServerLoaderProxy.postProcessBeforeInitialization(GeoServerLoaderProxy.java:59)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:394)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1448)
Also, I get literally TONS of these messages in the log. Then again, this also happens on the production 2.6.2 instance without causing any problems - apparently.
16 okt 15:06:34 ERROR [geotools.jdbc] - There’s code using JDBC based datastore and not disposing them. This may lead to temporary loss of database connections. Please make sure all data access code calls DataStore.dispose() before freeing all references to it
I ask again - what has apparently caused the Oracle driver - which I think is the culprit - to use so much more memory in 2.8 compared to 2.6? I’d like to emphasize once again, that my existing production server runs just fine.
I sincerely hope, that somebody here can provide some hints as to what I can do.
Thanks in advance,
Jacob Madsen