Re: [Geoserver-users] JDBCConfig export Catalog to XML Catalog in GEOSERVER DAT DIR

[Steve Omondi]

Hi Niels,

So I was trying out the Java class you shared. Here is what I did;
-> copied theJDBCexport into geoserver/WEB-INF/classes/
-> restarted the Tomcat
-> Tried to invoke the class on the browser with the following URLs;

http://host:port/geoserver/jdbcexport resulted into 404 Not Resource not
found
http://host:port/geoserver/rest/jdbcexport resulted into 403 Error
(Forbidden) Note that I'm logged into Geoserver as Admin

Is this the correct procedure I should use with this class?


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Kind regards,
Steve Omondi

On Wed, Nov 15, 2017 at 5:02 PM, Niels Charlier  wrote:

> Steve,
>
> Sorry for the confusion. This was not in response to you, but Andrea about
> dropping the module from geoserver altogether. I understand your decision
> because I have also found that  jdbcconfig is a problematic bottle neck
> (but as I mentioned, mostly because of the poor cache support and the
> unnecessarily repetitive queries).
>
> In the attachment you can find the code for exporting jdbc to hard drive.
> The file needs to be temporarily added to the class path and scanned by the
> spring appcontext, then when you are logged in as an admin you can call
> /jdbcexport from the browser to force the caching of the catalog. I hope
> you can use this somehow.
>
> Kind Regards
> Niels
>
>
> On 15-11-17 12:51, Steve Omondi wrote:
>
> Oh really, drop it? I thought jdbcconfig was the recommended way for
> clustering and is particularly useful when you are working with huge
> catalogs. I assumed it was actually being used in production by people.
>
> ​Our intention is not to drop it entirely. But to run more or less ​a
> catalog that is based on XML for some specific workspaces that we really
> need to be performant urgently.
>
>
> While we have found jdbcconfig to be an excellent solution for clustering,
> it
> also
> ​ ​
> has made *3 Load balanced Geoserver 2.11.2 to be 6 times slower than 1
> Geoserver 2.9* all other configurations kept constant.
> ​ And this is an issue that we can't ignore in PROD for our case.
>
> We intent to move a few of the workspaces and layers especially complex
> LayerGoups fron the JDBC catalog to achieve better performance over
> convenience of the DB Catalog.​
>
> *Otherwise, JDBCConfig is an excellent module in use*.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
>
> Kind regards,
> Steve Omondi
>
> On Wed, Nov 15, 2017 at 1:30 PM, Niels Charlier  wrote:
>
>> Oh really, drop it? I thought jdbcconfig was the recommended way for
>> clustering and is particularly useful when you are working with huge
>> catalogs. I assumed it was actually being used in production by people.
>>
>> The main problem seems to be the performance issues though, as this email
>> also proves, as well as both of the two PR's that are open who are related
>> to the same thing. But I believe this is rather solvable and would make a
>> huge difference.
>>
>> I can review these PRs no problem, since they are actually related to the
>> work I am doing for this module.
>>
>> Perhaps these improvements there can blow some new life into it.
>>
>> Regards
>>
>> Niels
>>
>> On 14-11-17 20:10, Andrea Aime wrote:
>>
>> Hi Niels,
>> today during the PSC meeting the topic came out of whether we should just
>> drop
>> JDBCConfig, since:
>>
>>- mails related to it are not really getting answered
>>- pull requests related to it are sitting there not getting reviewed
>>
>> We still have to see if there is some interested, but we need someone to
>> champion the module
>> just enough to make it worth keeping around (I'm not talking about
>> immediate answers, it's
>> a community/unsupported module, but at least some presence).
>> I'm also going to ping the people making pull requests.
>>
>> Cheers
>> Andrea
>>
>>
>> On Tue, Nov 14, 2017 at 5:24 PM, Niels Charlier  wrote:
>>
>>> Hello Steve,
>>>
>>> First I'd like to say I have been doing some work on considerable
>>> performance improvements for jdbcconfig. It  happens to be the case that
>>> jdbcconfig doesn't take good use of its cache and repeatedly sends the same
>>> queries over and over again. It looks promising but I still need to do some
>>> improvements and write some tests and I had other work coming on top of it.
>>> But this is definitely coming.
>>>
>>> Also, I wrote some code in geoserver for myself to conveniently export
>>> the jdbc catalog back to the file system. I found a way to do this easily
>>> by firing a bunch of catalog change events to the file system catalog.
>>> Howev

[Geoserver-users] Question about default tile expiration

[Paul Wittle via Geoserver-users]

Hi,

This is hopefully an easy question. On the tile settings tab for a layer there 
are two options for tile expiration (server and client). In brackets it states 
that setting these to 0 will default to the system default but where is the 
setting for the default?

I looked under Caching Defaults in 2.12.0 but I can't see an option and adding 
it to the GWC config file as  results in an error as well.

I have tried setting the values for a particular layer to 600 but I still get a 
header of Cache-Control: no-cache so we wanted to check what the default was 
set to.

I'm sure I'm missing something obvious but I thought I would ask anyway; any 
tips would be great?

Thanks,
Paul
"This e-mail is intended for the named addressee(s) only and may contain 
information about individuals or other sensitive information and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this email in error, kindly disregard the 
content of the message and notify the sender immediately. Please be aware that 
all email may be subject to recording and/or monitoring in accordance with 
relevant legislation."
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] JDBCConfig export Catalog to XML Catalog in GEOSERVER DAT DIR

[Niels Charlier]

No, applicationContext.xml

Regards

Niels


On 24-11-17 11:20, Steve Omondi wrote:

This is somewhere in WEB-IN/web.xml I presume?

Kind regards,
Steve Omondi

On Fri, Nov 24, 2017 at 1:09 PM, Niels Charlier > wrote:


Hi Steve,

You need to add a

| to
the spring context for it to work. Regards Niels |

On 24-11-17 09:20, Steve Omondi wrote:

So I temporarily removed security for the /rest/* chain in
Authentication and using
http://host:port/geoserver/rest/jdbcexport just returns the
defaultgeoserver/rest result.
Any pointers are welcome.
Kind regards,
Steve Omondi
On Fri, Nov 24, 2017 at 10:51 AM, Steve Omondi
mailto:steve.omo...@ramani.co.ke>>
wrote:

Hi Niels,
So I was trying out the Java class you shared. Here is what I
did;
-> copied theJDBCexport into geoserver/WEB-INF/classes/
-> restarted the Tomcat
-> Tried to invoke the class on the browser with the
following URLs;
http://host:port/geoserver/jdbcexport resulted into 404 Not
Resource not found
http://host:port/geoserver/rest/jdbcexport resulted into 403
Error (Forbidden) Note that I'm logged into Geoserver as Admin
Is this the correct procedure I should use with this class?


Virus-free. www.avast.com




Kind regards,
Steve Omondi
On Wed, Nov 15, 2017 at 5:02 PM, Niels Charlier
mailto:ni...@scitus.be>> wrote:

Steve,

Sorry for the confusion. This was not in response to you,
but Andrea about dropping the module from geoserver
altogether. I understand your decision because I have
also found that jdbcconfig is a problematic bottle neck
(but as I mentioned, mostly because of the poor cache
support and the unnecessarily repetitive queries).

In the attachment you can find the code for exporting
jdbc to hard drive. The file needs to be temporarily
added to the class path and scanned by the spring
appcontext, then when you are logged in as an admin you
can call /jdbcexport from the browser to force the
caching of the catalog. I hope you can use this somehow.

Kind Regards

Niels
On 15-11-17 12:51, Steve Omondi wrote:


Oh really, drop it? I thought jdbcconfig was the
recommended way for clustering and is particularly
useful when you are working with huge catalogs. I
assumed it was actually being used in production by
people.

​Our intention is not to drop it entirely. But to run
more or less ​a catalog that is based on XML for some
specific workspaces that we really need to be performant
urgently.
While we have found jdbcconfig to be an excellent
solution for clustering, it
also
​ ​
has made *3 Load balanced Geoserver 2.11.2 to be 6 times
slower than 1 Geoserver 2.9* all other configurations
kept constant.
​ And this is an issue that we can't ignore in PROD for
our case.
We intent to move a few of the workspaces and layers
especially complex LayerGoups fron the JDBC catalog to
achieve better performance over convenience of the DB
Catalog.​
*Otherwise, JDBCConfig is an excellent module in use*.


Virus-free. www.avast.com




Kind regards,
Steve Omondi
On Wed, Nov 15, 2017 at 1:30 PM, Niels Charlier
mailto:ni...@scitus.be>> wrote:

Oh really, drop it? I thought jdbcconfig was the
recommended way for clustering and is particularly
useful when you are working with huge catalogs. I
assumed it was actually being used in production by
people.

The main problem seems to be the performance issues
though, as this email also proves, as well as both
of the two PR's that are open who are related to the
same thing. But I believe this is rather solvable
and would make a huge difference.

I can review these PRs no problem, since they are
actual

Re: [Geoserver-users] JDBCConfig export Catalog to XML Catalog in GEOSERVER DAT DIR

[Steve Omondi]

This is somewhere in WEB-IN/web.xml I presume?

Kind regards,
Steve Omondi

On Fri, Nov 24, 2017 at 1:09 PM, Niels Charlier  wrote:

> Hi Steve,
>
> You need to add a
>
> 
>
> to the spring context for it to work.
>
> Regards
> Niels
>
>
> On 24-11-17 09:20, Steve Omondi wrote:
>
> So I temporarily removed security for the /rest/* chain in Authentication
> and using http://host:port/geoserver/rest/jdbcexport just returns the
> default geoserver/rest result.
>
> Any pointers are welcome.
>
> Kind regards,
> Steve Omondi
>
> On Fri, Nov 24, 2017 at 10:51 AM, Steve Omondi 
> wrote:
>
>> Hi Niels,
>>
>> So I was trying out the Java class you shared. Here is what I did;
>> -> copied theJDBCexport into geoserver/WEB-INF/classes/
>> -> restarted the Tomcat
>> -> Tried to invoke the class on the browser with the following URLs;
>>
>> http://host:port/geoserver/jdbcexport resulted into 404 Not Resource not
>> found
>> http://host:port/geoserver/rest/jdbcexport resulted into 403 Error
>> (Forbidden) Note that I'm logged into Geoserver as Admin
>>
>> Is this the correct procedure I should use with this class?
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>>
>> Kind regards,
>> Steve Omondi
>>
>> On Wed, Nov 15, 2017 at 5:02 PM, Niels Charlier  wrote:
>>
>>> Steve,
>>>
>>> Sorry for the confusion. This was not in response to you, but Andrea
>>> about dropping the module from geoserver altogether. I understand your
>>> decision because I have also found that  jdbcconfig is a problematic bottle
>>> neck (but as I mentioned, mostly because of the poor cache support and the
>>> unnecessarily repetitive queries).
>>>
>>> In the attachment you can find the code for exporting jdbc to hard
>>> drive. The file needs to be temporarily added to the class path and scanned
>>> by the spring appcontext, then when you are logged in as an admin you can
>>> call /jdbcexport from the browser to force the caching of the catalog. I
>>> hope you can use this somehow.
>>>
>>> Kind Regards
>>> Niels
>>>
>>>
>>> On 15-11-17 12:51, Steve Omondi wrote:
>>>
>>> Oh really, drop it? I thought jdbcconfig was the recommended way for
>>> clustering and is particularly useful when you are working with huge
>>> catalogs. I assumed it was actually being used in production by people.
>>>
>>> ​Our intention is not to drop it entirely. But to run more or less ​a
>>> catalog that is based on XML for some specific workspaces that we really
>>> need to be performant urgently.
>>>
>>>
>>> While we have found jdbcconfig to be an excellent solution for
>>> clustering, it
>>> also
>>> ​ ​
>>> has made *3 Load balanced Geoserver 2.11.2 to be 6 times slower than 1
>>> Geoserver 2.9* all other configurations kept constant.
>>> ​ And this is an issue that we can't ignore in PROD for our case.
>>>
>>> We intent to move a few of the workspaces and layers especially complex
>>> LayerGoups fron the JDBC catalog to achieve better performance over
>>> convenience of the DB Catalog.​
>>>
>>> *Otherwise, JDBCConfig is an excellent module in use*.
>>>
>>>
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>>
>>> Kind regards,
>>> Steve Omondi
>>>
>>> On Wed, Nov 15, 2017 at 1:30 PM, Niels Charlier  wrote:
>>>
 Oh really, drop it? I thought jdbcconfig was the recommended way for
 clustering and is particularly useful when you are working with huge
 catalogs. I assumed it was actually being used in production by people.

 The main problem seems to be the performance issues though, as this
 email also proves, as well as both of the two PR's that are open who are
 related to the same thing. But I believe this is rather solvable and would
 make a huge difference.

 I can review these PRs no problem, since they are actually related to
 the work I am doing for this module.

 Perhaps these improvements there can blow some new life into it.

 Regards

 Niels

 On 14-11-17 20:10, Andrea Aime wrote:

 Hi Niels,
 today during the PSC meeting the topic came out of whether we should
 just drop
 JDBCConfig, since:

- mails related to it are not really getting answered
- pull requests related to it are sitting there not getting reviewed

 We still have to see if there is some interested, but we need someone
 to champion the module
 just enough to make it worth keeping around (I'm not talking about
 immediate answers, it's
 a community/unsupported module, but at least some presence).
 I'm also going to ping the people 

Re: [Geoserver-users] JDBCConfig export Catalog to XML Catalog in GEOSERVER DAT DIR

[Niels Charlier]

Hi Steve,

You need to add a

| to the 
spring context for it to work. Regards Niels |



On 24-11-17 09:20, Steve Omondi wrote:
So I temporarily removed security for the /rest/* chain in 
Authentication and using http://host:port/geoserver/rest/jdbcexport 
just returns the defaultgeoserver/rest result.


Any pointers are welcome.

Kind regards,
Steve Omondi

On Fri, Nov 24, 2017 at 10:51 AM, Steve Omondi 
mailto:steve.omo...@ramani.co.ke>> wrote:


Hi Niels,

So I was trying out the Java class you shared. Here is what I did;
-> copied theJDBCexport into geoserver/WEB-INF/classes/
-> restarted the Tomcat
-> Tried to invoke the class on the browser with the following URLs;

http://host:port/geoserver/jdbcexport resulted into 404 Not
Resource not found
http://host:port/geoserver/rest/jdbcexport resulted into 403 Error
(Forbidden) Note that I'm logged into Geoserver as Admin

Is this the correct procedure I should use with this class?



Virus-free. www.avast.com





Kind regards,
Steve Omondi

On Wed, Nov 15, 2017 at 5:02 PM, Niels Charlier mailto:ni...@scitus.be>> wrote:

Steve,

Sorry for the confusion. This was not in response to you, but
Andrea about dropping the module from geoserver altogether. I
understand your decision because I have also found that
jdbcconfig is a problematic bottle neck (but as I mentioned,
mostly because of the poor cache support and the unnecessarily
repetitive queries).

In the attachment you can find the code for exporting jdbc to
hard drive. The file needs to be temporarily added to the
class path and scanned by the spring appcontext, then when you
are logged in as an admin you can call /jdbcexport from the
browser to force the caching of the catalog. I hope you can
use this somehow.

Kind Regards

Niels


On 15-11-17 12:51, Steve Omondi wrote:


Oh really, drop it? I thought jdbcconfig was the
recommended way for clustering and is particularly useful
when you are working with huge catalogs. I assumed it was
actually being used in production by people.

​Our intention is not to drop it entirely. But to run more or
less ​a catalog that is based on XML for some specific
workspaces that we really need to be performant urgently.


While we have found jdbcconfig to be an excellent solution
for clustering, it
also
​ ​
has made *3 Load balanced Geoserver 2.11.2 to be 6 times
slower than 1 Geoserver 2.9* all other configurations kept
constant.
​ And this is an issue that we can't ignore in PROD for our case.

We intent to move a few of the workspaces and layers
especially complex LayerGoups fron the JDBC catalog to
achieve better performance over convenience of the DB Catalog.​

*Otherwise, JDBCConfig is an excellent module in use*.





Virus-free. www.avast.com





Kind regards,
Steve Omondi

On Wed, Nov 15, 2017 at 1:30 PM, Niels Charlier
mailto:ni...@scitus.be>> wrote:

Oh really, drop it? I thought jdbcconfig was the
recommended way for clustering and is particularly useful
when you are working with huge catalogs. I assumed it was
actually being used in production by people.

The main problem seems to be the performance issues
though, as this email also proves, as well as both of the
two PR's that are open who are related to the same thing.
But I believe this is rather solvable and would make a
huge difference.

I can review these PRs no problem, since they are
actually related to the work I am doing for this module.

Perhaps these improvements there can blow some new life
into it.

Regards

Niels


On 14-11-17 20:10, Andrea Aime wrote:

Hi Niels,
today during the PSC meeting the topic came out of
whether we should just drop
JDBCConfig, since:

  * mails related to it are not really getting answered
  * pull requests related to it are sitting there not
getting reviewed

We still have to see if there is some interested, but we
need 

Re: [Geoserver-users] JDBCConfig export Catalog to XML Catalog in GEOSERVER DAT DIR

[Steve Omondi]

So I temporarily removed security for the /rest/* chain in Authentication
and using http://host:port/geoserver/rest/jdbcexport just returns the
default geoserver/rest result.

Any pointers are welcome.

Kind regards,
Steve Omondi

On Fri, Nov 24, 2017 at 10:51 AM, Steve Omondi 
wrote:

> Hi Niels,
>
> So I was trying out the Java class you shared. Here is what I did;
> -> copied theJDBCexport into geoserver/WEB-INF/classes/
> -> restarted the Tomcat
> -> Tried to invoke the class on the browser with the following URLs;
>
> http://host:port/geoserver/jdbcexport resulted into 404 Not Resource not
> found
> http://host:port/geoserver/rest/jdbcexport resulted into 403 Error
> (Forbidden) Note that I'm logged into Geoserver as Admin
>
> Is this the correct procedure I should use with this class?
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-6294030542967299794_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Kind regards,
> Steve Omondi
>
> On Wed, Nov 15, 2017 at 5:02 PM, Niels Charlier  wrote:
>
>> Steve,
>>
>> Sorry for the confusion. This was not in response to you, but Andrea
>> about dropping the module from geoserver altogether. I understand your
>> decision because I have also found that  jdbcconfig is a problematic bottle
>> neck (but as I mentioned, mostly because of the poor cache support and the
>> unnecessarily repetitive queries).
>>
>> In the attachment you can find the code for exporting jdbc to hard drive.
>> The file needs to be temporarily added to the class path and scanned by the
>> spring appcontext, then when you are logged in as an admin you can call
>> /jdbcexport from the browser to force the caching of the catalog. I hope
>> you can use this somehow.
>>
>> Kind Regards
>> Niels
>>
>>
>> On 15-11-17 12:51, Steve Omondi wrote:
>>
>> Oh really, drop it? I thought jdbcconfig was the recommended way for
>> clustering and is particularly useful when you are working with huge
>> catalogs. I assumed it was actually being used in production by people.
>>
>> ​Our intention is not to drop it entirely. But to run more or less ​a
>> catalog that is based on XML for some specific workspaces that we really
>> need to be performant urgently.
>>
>>
>> While we have found jdbcconfig to be an excellent solution for
>> clustering, it
>> also
>> ​ ​
>> has made *3 Load balanced Geoserver 2.11.2 to be 6 times slower than 1
>> Geoserver 2.9* all other configurations kept constant.
>> ​ And this is an issue that we can't ignore in PROD for our case.
>>
>> We intent to move a few of the workspaces and layers especially complex
>> LayerGoups fron the JDBC catalog to achieve better performance over
>> convenience of the DB Catalog.​
>>
>> *Otherwise, JDBCConfig is an excellent module in use*.
>>
>>
>>
>>
>> 
>>  Virus-free.
>> www.avast.com
>> 
>>
>> Kind regards,
>> Steve Omondi
>>
>> On Wed, Nov 15, 2017 at 1:30 PM, Niels Charlier  wrote:
>>
>>> Oh really, drop it? I thought jdbcconfig was the recommended way for
>>> clustering and is particularly useful when you are working with huge
>>> catalogs. I assumed it was actually being used in production by people.
>>>
>>> The main problem seems to be the performance issues though, as this
>>> email also proves, as well as both of the two PR's that are open who are
>>> related to the same thing. But I believe this is rather solvable and would
>>> make a huge difference.
>>>
>>> I can review these PRs no problem, since they are actually related to
>>> the work I am doing for this module.
>>>
>>> Perhaps these improvements there can blow some new life into it.
>>>
>>> Regards
>>>
>>> Niels
>>>
>>> On 14-11-17 20:10, Andrea Aime wrote:
>>>
>>> Hi Niels,
>>> today during the PSC meeting the topic came out of whether we should
>>> just drop
>>> JDBCConfig, since:
>>>
>>>- mails related to it are not really getting answered
>>>- pull requests related to it are sitting there not getting reviewed
>>>
>>> We still have to see if there is some interested, but we need someone to
>>> champion the module
>>> just enough to make it worth keeping around (I'm not talking about
>>> immediate answers, it's
>>> a community/unsupported module, but at least some presence).
>>> I'm also going to ping the people making pull requests.
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Tue, Nov 14, 2017 at 5:24 PM, Niels Charlier  wrote:
>>>
 Hello Steve,

 First I'd like to say I have been doing some work on considerable
 performance improvements for jdbcconfig. It  happens to be the case that
 jdbcconfig doesn't take good use of its cache and repe