Thanks for your response Nicolas.  Based on what you and Andrea have said, it 
sounds like the Hibernate extension does not have maintenance support and aside 
from that does not perform well, e.g. would add excessive db load, etc.  We 
don’t have a lot of users as of now and were mainly serving WFS rather than 
tiled WMS, so we’re probably not seeing the volume you are.

Your Monitor Filter extension sounds interesting, though I don’t have any 
experience developing plugins for GeoServer, but will look over the GeoServer 
development docs and see if that’s something I can take on.  My other thought 
was to collect and parse log files periodically.  We don’t have a critical need 
for near-real time monitoring so much as getting historical trends of data 
usage.  Though now that I think about it, creating a plugin might be cleaner 
and less lift.  Regardless, it sounds like we’ll need to come up with a custom 
solution for our needs.  If we end up working on a plugin, we’ll see if it is 
something worth contributing back.

From: Nicolas Fagart <[email protected]>
Date: Friday, July 12, 2019 at 2:34 AM
To: "Nugent, Phil" <[email protected]>
Cc: geoserver-users <[email protected]>
Subject: [EXTERNAL] Re: [Geoserver-users] Monitoring Extension with Hibernate 
Persistence

Hello,

On our platform, we were using also the Monitor Extension with Hibernate with 
GeoServer 2.12 but we had several issues with that extension, especially with 
the implementation with Hibernate:
- Performance issue: If I'm not wrong, there was one database query every 
single user HTTP request... so one per tile !
- Version conflict with other Geoserver extensions (the Monitor was based on 
old deprecated Hibernate lib)
- Lack of maintenance & support (nobody was really working on that extension, 
missing time)

=> We got rid of that Monitor extension.
We could have tried to improve the Extension. But we did not have time to get 
inlvolved into the GeoServer Extension development. Also we wanted to add very 
specific custom request parameters to monitor (like sort of authkey), so we 
decided to implement our own custom Monitor Filter. That was not so difficult 
to achieve.

The idea is to create your own Monitor class implementing the interface 
javax.servlet.Filter
For information, in our implementation, we manage an equivalent 'request' table 
(same as the standard Monitor table + few additional columns) to store all 
single requests in the DB.
But the process also archive weekly the requests in another 'archive' table 
(aggregated by day/user/resource/ip...) to merge the Tile Requests
So the 'request' table keep only the requests for the last month to avoid to 
increase dramatically.

Also to limit the number of database queries, our Monitor track all HTTP 
request, but keep that in memory on the Filter App and flush all the requests 
(asynchronously) in the database every 3 or 5 minutes. And that made a huge 
difference (before we could have thousands of requests every minutes).

Best regards,
Nicolas FAGART

Le jeu. 11 juil. 2019 à 16:56, Nugent, Phil via Geoserver-users 
<[email protected]<mailto:[email protected]>>
 a écrit :
Hello all,

I’ve been using the Monitor extension in GeoServer version 2.12 for about a 
year experimenting with the REST API with the hopes of collecting request data 
for gauging user interest in various data.  We are at the point of wanting to 
take that a step further, which will necessitate installing the Hibernate 
Monitor community extension to persist the request data.  I thought I would 
upgrade to the latest stable version of GeoServer while I was at it, but I 
noticed there is not a build for the community extension past 2.14 and saw that 
the extension has been removed from nightly builds.  So I guess I have two 
questions:

Does anyone know the future of the Hibernate Monitor extension and the Monitor 
extension proper?

And is there a good way to build the extension locally for a newer version or 
is there another method for persisting request data that I am missing?

Thank you for your time,
Phil Nugent
_______________________________________________
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

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-users
_______________________________________________
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

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to