Dear Andrea,
Thanks for this.
My colleagues have tested nightly build version with 3,000 layers from just one
data store and got the results like this. It took around 3 minutes and 40
seconds as opposed to 20 minutes with old GeoServer 2.10. It seems there’s much
improvement.
However my
On Sun, Dec 18, 2016 at 6:57 PM, Jaroslav Urik wrote:
> Hi Andrea,
>
> sorry for this late answer, I was AFK on vacation for last 14 days.
> I would like to thank you for all this work you have done!
> I am really looking forward to testing this
>
One of the two pull
Hi Andrea,
sorry for this late answer, I was AFK on vacation for last 14 days.
I would like to thank you for all this work you have done!
I am really looking forward to testing this
Thank you very much and have a nice Christmas =)
Kind regards,
Jaroslav
On Sat, Dec 10, 2016 at 11:40 AM
Hi,
for those interested, I've prepared a couple of pull requests to deal with
these issues. Not sure
when they are going to land on 2.10 and 2.9, right now they are pending
review:
https://github.com/geoserver/geoserver/pull/1999
https://github.com/geoserver/geoserver/pull/2008
Cheers
Andrea
I'm afraid this won't help as the code I've discovered is in the GWC
integration and independent of
how the storage is setup.
The only way to get rid of it without changing the code would be to remove
all gwc jars from GeoServer (which is btw completely feasible, if one does
not need caching/WMTS)
I haven’t tested this in a while, but we experienced this problem in the past
and discovered that using the JDBC-Config plugin (from community modules)
resolved the issue. There is an initial hit during the first run with
JDBC-Config enabled as it reads every resource file, validates it, and
Oook, think I've found it... yesterday I thought the startup was complete,
but I was wrong (was late, got tired).
In the trailing end of the startup GWC there is a check verifying that each
vector layer has as geometry
column (in other terms, that it's not geometryless).
This triggers the
Hi,
I've tried to setup locally an artificial test case with lots of layers,
checking if by any chance it's just that
which is making things "bad".
Local setup:
- GeoServer development series (2.11.x)
- Postgresql/Postgis
- One store, one database
- 1 layers, each one with its own
Hi Andrea,
I filed a ticket since I think this symptom is very similar to the one I posted
a couple of days ago. I talked with Andy who experienced similar issue but
found no solution. Hope this get fixed soon.
Warm regards,
신상희 드림
[1] https://osgeo-org.atlassian.net/browse/GEOS-7884
---
On Thu, Dec 1, 2016 at 2:36 PM, Jaroslav Urik wrote:
> Hi,
> I have the same problem as described in [1] -- I am running GeoServer
> under Tomcat with a lot of georeferenced maps ( about 65 000 ) and it takes
> very long time to start - about 3-4 hours.
> The problem seems
Hi,
we don't know why it's happening but you're not the first to report it.
I already asked in vain for someone to report a ticket with some details at
https://osgeo-org.atlassian.net/projects/GEOS/issues ?
If there is no bug report, for sure nobody will look into it when the
monthly bug fix code
Yes, that might solve it, but I do not know how to achieve this.. Also I
hope that geonetwork just check if file exist and does not read the whole
file..
On Thu, Dec 1, 2016 at 3:09 PM Julian Hollingbery
wrote:
> … or possibly running these checks in parallel?
>
>
>
>
… or possibly running these checks in parallel?
Fra: Jaroslav Urik [mailto:jarda.u...@gmail.com]
Sendt: 1. december 2016 14:36
Til: geoserver-users@lists.sourceforge.net
Emne: [Geoserver-users] GeoServer Slow to Start with Lots of Namespaces ( > 3h )
Hi,
I have the same problem as described in
13 matches
Mail list logo