I believe that is a problem of the filesize of the WAR file of geoserver.
At default tomcat only accepts 50MB in the WAR files to upload, open with notepad the file: C:\Program Files (x86)\Apache Software Foundation\Tomcat 9.0\webapps\manager\WEB-INF\web.xml
and find the lines with the text: <max-file-size> and <max-request-size>.
This problem occurs when your .war is bigger than the value in config file of the tomcat manager.
You need to set the config in web.xml from the tomcat manager.
The file will normally be in %tomcat installation%\webapps\manager\WEB-INF\web.xml
<!-- 50MB max -->
GeoServer is a Java web application packaged as a WAR file. It needs to be deployed in a Java servlet container of which Apache Tomcat is an implementation. You could also use another servlet engine like Jetty. So in order to use GeoServer, you will be obliged to use a Java servlet container.
If you want to avoid the use of a servlet engine, you could also ...
generally speaking I would give GeoServer an amount of heap memory between 1GB and 8GB.
It is rather difficult that it will use more than that.
It would actually be great if yoy could say more about what kind of data you are serving with GeoServer and which kind of requests you are usually sending to it. A stack trace might help as well.
Well, I gleaned this information from many different posts. There are several "answers" out there, but I only found one that actually worked.
First of all, if you are running Tomcat 8.0 as a service in the Windows OS, those BAT files (catalina.bat, setenv.bat if you created one) do not seem to be relevant at all. There are many who say "edit catalina....
The best way to do this is with a Reverse Proxy in front of GeoServer.
You can do it with Nginx.
Here's an example: https://gist.github.com/thanhleviet/3040490
The 'proxy base URL' setting in GeoServer allows you to tell GeoServer that it is behind one of these proxies, and adjusts all it's WMS Capabilities URLs and such (from my understanding).
geoserver.exe installs GeoServer as a windows service (or optionally as a manually started program) running inside Jetty. geoserver.war is a platform independant war file that needs to be installed into a container server (e.g. tomcat, jboss, jetty etc).
The downside of using the exe installer is that you have to be on a windows machine, you also get less ...
Your first app is attempting to load the web map from a file:// uri (see the Chrome console error: "Unable to load file://www.arcgis.com/sharing/...") and not http (or https) as it should.
Are you sure you are hosting the html in a page served out by your web server and not just double clicking it to open directly from the file system?
I suspect an out of memory error: the first application to be accessed will issue a large (how many features are fetched with every layer?) WFS request which completes, but prevents further requests from being carried out successfully.
This explains the works-after-restart behaviour as with a restart all JVM memory would be released and then reallocated ...
You should be pointing OpenLayers to a local proxy. Not the proxy on GeoServer.
For example, my OpenLayers.ProxyHost property is like:
OpenLayers.ProxyHost = "proxy/proxy.ashx?url=";
But you might want something like this:
OpenLayers.ProxyHost = "/cgi-bin/proxy.cgi?url=";
There a two or three possible reasons that come to my mind:
Option1: your Webserver is not configured properly:
What happens for example if you try to access this site(presuming that you put your proxy.cgi in your usr/lib/cgi-bin -folder):
If you wont see the openstreetmap-...
The real cause of the issue is the max-file-size limit in WEB-INF/web.xml. It is set for 50MB while the geoserver.war (version 2.9.0) is over 65MB.
Open the file below for tomcat7:
sudo nano /usr/share/tomcat7-admin/manager/WEB-INF/web.xml
Locate multipart-config tag and turn 50MB to 500MB.
GeoServer is a servlet and always runs inside a servlet container (e.g. tomcat, jetty, JBoss etc). So your question is "how do I change the port of the container that GeoServer is using?" which is what the question you point to is answering.
On the OSGeoLive VM there are two tomcat containers running one on port 8080 and the other (with GeoServer) on 8082. ...
GeoServer's GDAL extension is very picky about the version of GDAL you need - please follow the instructions in the extension documentation.
This is due to the way the JAva to C(++) bindings work and to be honest is something of a mystery to Java developers but seems to keep the C++ boys happy.
On startup GeoServer loads the configuration of all layers, to be kept in memory. The process makes it load NumberOfLayers*2 files just for the layers, plus all styles, stores and whatnot.
While I cannot be sure that is the problem, it seems that GeoServer is going to take several minutes to startup in those conditions, and the situation will worsen daily.
Edit the tomcat configuration file (in conf/server.xml) and add an AccessLog Valve.
The common log format already logs the username along with url and is common in the sense that most log processing tool can process it out of the box.
To work with geocoder in OTP please refer to this post. here
There are some slight improvements to the above post though( I have to spent hours to figure them out!), these are as follows
For Google basemap
In config.js just add these codes after the OSM declaration in baselayers:
Add the Google Maps ...
The short answer is you could, but you shouldn't.
Messing with the internal Tomcat is not recommended and will likely give you issues with Esri technical support if you encounter issues with ArcGIS Server.
I have done some playing about with the internal Tomcat at 10.1 and the message from Esri is, don't do it (understandably as it might have knock on ...
You forgetting to copy the *jni.so files to your shared library folder.
As state on gdal java documentation http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix:
To deploy you need gdal.jar in your class path, the 4 .so files (libgdalconstjni.so, libgdaljni.so, libogrjni.so and libosrjni.so) and
libgdal.so in your shared library path.
maybe I overlooked something but from the outside you are accessing
as the default port for Apache HTTP is port 80, hence connecting to port 8080 on it would give you exactly that error.
Computing disk usage for the entire cache directory is expensive so there's a module in GWC called Disk Quota which maintains a running total for each layer as tiles are added and removed. By default, Disk Quota is turned off, which results in the 0 values you see. Turn on DiskQuota (in the sidebar under "Tile Caching") and it will start showing the correct ...
The page Building and installing the PHP GDAL extension in the Drupal Community Documentation is helpful.
The main part being to download and install from source, php5-gdal from its github repository. Some development tools may need to be installed before-hand.
sudo make install
Then configure and enable the module.
sudo echo -e ...
I fixed it!
If you layer in the Publishing tab, in the list of "Selected Styles" have records of styles, then we get this error.
I deleted the source Geoserver 2.2 these records and to save the layer. Moved workspace to a new Geoserver abd can see all the layers!
You cannot have different tomcats listening to the same port.
Said that, it is good to have separated tomcats for big java apps, just because if one of them have problems like running out of memory, you can restart that app without having to bother the other app. Running out of memory is common for certain use cases on geoServer. So, it really depends on ...