[Geoserver-users] symbolic link to Geoserver deployment

Lehtonen_Mika · May 27, 2009, 11:55am

Hi,
I have been using symbolic links for controlling which Geoserver version I am using. (Linux, Tomcat) The problem is that recent versions can't be used that way. Does anyone know why? For example, I have working Geoserver deployments gs163 and gs174:
'ln -s gs163 geoserver1' works (http://host.domain/geoserver1/),
'ln -s gs174 geoserver2' doesn't (http://host.domain/geoserver2/), I get http 404 error

- mika -

Andrea_Aime3 · May 28, 2009, 1:20pm

Lehtonen, Mika ha scritto:

Hi,
I have been using symbolic links for controlling which Geoserver version I am using. (Linux, Tomcat) The problem is that recent versions can't be used that way. Does anyone know why? For example, I have working Geoserver deployments gs163 and gs174:
'ln -s gs163 geoserver1' works (http://host.domain/geoserver1/),
'ln -s gs174 geoserver2' doesn't (http://host.domain/geoserver2/), I get http 404 error

Can you elaborate? What is the link controlling? The geoserver under
tomcat, the data directory?
Never tried this actually.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Lehtonen_Mika · May 28, 2009, 1:38pm

Hi,
yes, the geoserver under Tomcat. I explain shortly what I have usually done:
1) I download the latest stable Geoserver war distribution and unzip it.
2) I rename the geoserver.war with the name describing the version, like gs174.war
3) I move that war into Tomcat's directory where it will autodeploy. (I am using virtual host configuration in Tomcat so the new Geoserver can be accessed from http://subdomain.domain/gs174/)
4) After that I create a symbolic link into that very directory, for example geoserver, which points at the deployed geoserver (gs174). After that I can access the new geoserver version with a link: http://subdomain.domain/geoserver/

This has been an easy way to control different versions. I have applications which have http://subdomain.domain/geoserver/ hardcoded. Changing the gs version has been easy by changing the link. But for some reason, it doesn't work in 1.74 anymore.

- mika -

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Hi,
I have been using symbolic links for controlling which Geoserver version I am using. (Linux, Tomcat) The problem is that recent versions can't be used that way. Does anyone know why? For example, I have working Geoserver deployments gs163 and gs174:
'ln -s gs163 geoserver1' works (http://host.domain/geoserver1/),
'ln -s gs174 geoserver2' doesn't (http://host.domain/geoserver2/), I get http 404 error

Can you elaborate? What is the link controlling? The geoserver under
tomcat, the data directory?
Never tried this actually.

Cheers
Andrea

Lehtonen_Mika · June 3, 2009, 11:27am

So,
anyone hasn’t got any clue if something has changed in Geoserver war so that deployed Geoserver can’t be reached through symbolic link any more?

mika -

Mika Lehtonen kirjoitti:

Andrea_Aime3 · June 4, 2009, 7:09am

Lehtonen, Mika ha scritto:

So,
anyone hasn't got any clue if something has changed in Geoserver war so that deployed Geoserver can't be reached through symbolic link any more?

I tried what you suggested, in the startup logs I've noticed this:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)
  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)
  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)
  ... 41 more
Caused by: org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
  at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:59)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
  ... 43 more

So I guess the problem is with GWC embedded tile database, it cannot be
opened twice. In your setup you basically have two GeoServer running
against the same data directory, and the startup in the second one
fails during startup trying to get a hold of the same db the first
one has already opened.

Arne, afaik a way was to remove the GWC jars from GeoServer?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Arne_Kepp · June 4, 2009, 7:14am

Andrea Aime wrote:

Lehtonen, Mika ha scritto:

So,
anyone hasn't got any clue if something has changed in Geoserver war so that deployed Geoserver can't be reached through symbolic link any more?

I tried what you suggested, in the startup logs I've noticed this:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)

    at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)

    ... 41 more
Caused by: org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:59)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
    ... 43 more

So I guess the problem is with GWC embedded tile database, it cannot be
opened twice. In your setup you basically have two GeoServer running
against the same data directory, and the startup in the second one
fails during startup trying to get a hold of the same db the first
one has already opened.

Arne, afaik a way was to remove the GWC jars from GeoServer?
Cheers
Andrea

Yeah, so it actually looks like Tomcat is treating these as two distinct servlets, meaning your memory consumption (at least as far as permgen is concerned) will be double too.

Currently the only way to deal with that is to remove gwc*.jar and geowebcache*.jar from the WEB-INF/lib directory and restart.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Lehtonen_Mika · June 4, 2009, 7:20am

Ok,
thanks. So this has not been very clever, although I have found it to be extremely handy. Have to think of some other way..

- mika -

Arne Kepp kirjoitti:

Andrea Aime wrote:

Lehtonen, Mika ha scritto:

So,
anyone hasn't got any clue if something has changed in Geoserver war so that deployed Geoserver can't be reached through symbolic link any more?

I tried what you suggested, in the startup logs I've noticed this:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)

    at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)

    ... 41 more
Caused by: org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:59)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
    ... 43 more

So I guess the problem is with GWC embedded tile database, it cannot be
opened twice. In your setup you basically have two GeoServer running
against the same data directory, and the startup in the second one
fails during startup trying to get a hold of the same db the first
one has already opened.

Arne, afaik a way was to remove the GWC jars from GeoServer?
Cheers
Andrea

Yeah, so it actually looks like Tomcat is treating these as two distinct servlets, meaning your memory consumption (at least as far as permgen is concerned) will be double too.

Currently the only way to deal with that is to remove gwc*.jar and geowebcache*.jar from the WEB-INF/lib directory and restart.

-Arne

Andrea_Aime3 · June 4, 2009, 7:23am

Lehtonen, Mika ha scritto:

Ok,
thanks. So this has not been very clever, although I have found it to be extremely handy. Have to think of some other way..

Tomcat "deploying" a war really just means unzipping the .war for it.

So I guess you can put your GeoServer in some folder other than webapps,
unzip it, create a symbolic link from webapps to the unzipped folder.
That should do the trick

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Arne_Kepp · June 4, 2009, 7:23am

Shrug, RAM is (contrary to popular belief) is cheap, people's time is not. I would just go for it if you dont need GWC.

I will make it possible to disable the metastore (and continue with a limited set of features) soon, it's implemented on trunk and in 1.1..1.

-Arne

Lehtonen, Mika wrote:

Ok,
thanks. So this has not been very clever, although I have found it to be extremely handy. Have to think of some other way..

- mika -

Arne Kepp kirjoitti:

Andrea Aime wrote:

Lehtonen, Mika ha scritto:

So,
anyone hasn't got any clue if something has changed in Geoserver war so that deployed Geoserver can't be reached through symbolic link any more?

I tried what you suggested, in the startup logs I've noticed this:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)

    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)

    at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)

    ... 41 more
Caused by: org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:59)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)

    ... 43 more

So I guess the problem is with GWC embedded tile database, it cannot be
opened twice. In your setup you basically have two GeoServer running
against the same data directory, and the startup in the second one
fails during startup trying to get a hold of the same db the first
one has already opened.

Arne, afaik a way was to remove the GWC jars from GeoServer?
Cheers
Andrea

Yeah, so it actually looks like Tomcat is treating these as two distinct servlets, meaning your memory consumption (at least as far as permgen is concerned) will be double too.

Currently the only way to deal with that is to remove gwc*.jar and geowebcache*.jar from the WEB-INF/lib directory and restart.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Lehtonen_Mika · June 4, 2009, 7:41am

That's very true! But I am afraid I will be needing GWC, if not now, then in the near future. Actually I tried it and didn't get it working. So the reason is most probably this dublicated deployment. Have to test it without the link.

- mika -

BTW: Andrea, your approach doesn't seem to be bad at all either.

Arne Kepp kirjoitti:

Shrug, RAM is (contrary to popular belief) is cheap, people's time is not. I would just go for it if you dont need GWC.

I will make it possible to disable the metastore (and continue with a limited set of features) soon, it's implemented on trunk and in 1.1..1.

-Arne

Lehtonen, Mika wrote:

Ok,
thanks. So this has not been very clever, although I have found it to be extremely handy. Have to think of some other way..

- mika -

Arne Kepp kirjoitti:

Andrea Aime wrote:

Lehtonen, Mika ha scritto:

So,
anyone hasn't got any clue if something has changed in Geoserver war so that deployed Geoserver can't be reached through symbolic link any more?

I tried what you suggested, in the startup logs I've noticed this:

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend]: Constructor threw exception; nested exception is org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:115)

    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:87)

    at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:248)

    ... 41 more
Caused by: org.geowebcache.storage.StorageException: Database may be already in use: Locked by another process. Possible solutions: close all other connection(s); use the server mode [90020-104]
    at org.geowebcache.storage.metastore.jdbc.JDBCMetaBackend.<init>(JDBCMetaBackend.java:59)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)

    ... 43 more

So I guess the problem is with GWC embedded tile database, it cannot be
opened twice. In your setup you basically have two GeoServer running
against the same data directory, and the startup in the second one
fails during startup trying to get a hold of the same db the first
one has already opened.

Arne, afaik a way was to remove the GWC jars from GeoServer?
Cheers
Andrea

Yeah, so it actually looks like Tomcat is treating these as two distinct servlets, meaning your memory consumption (at least as far as permgen is concerned) will be double too.

Currently the only way to deal with that is to remove gwc*.jar and geowebcache*.jar from the WEB-INF/lib directory and restart.

-Arne

Arne_Kepp · June 4, 2009, 7:44am

Lehtonen, Mika wrote:

BTW: Andrea, your approach doesn't seem to be bad at all either.

In fact, it's a much better idea. We use symlinks on our servers too, but for the entire webapp directory.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Lehtonen_Mika · June 4, 2009, 10:38am

Works just fine.
Thanks. Best solutions are often too obvious.

- mika -

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Ok,
thanks. So this has not been very clever, although I have found it to be extremely handy. Have to think of some other way..

Tomcat "deploying" a war really just means unzipping the .war for it.

So I guess you can put your GeoServer in some folder other than webapps,
unzip it, create a symbolic link from webapps to the unzipped folder.
That should do the trick

Cheers
Andrea