Hello,
What people think about reducing the log level (from ERROR to INFO) for messages generated when a client requests a feature type that does not exist?
These requests do not indicate a problem with the server, and the client is correctly served a response indicating that the feature type does not exist.
Currently it’s possible for a single misguided client to flood the logs by requesting feature types that do not exist.
Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
Hi Daniel,
on my side I see it as a good thing, we already have some specialized logic to avoid
logging stack traces when the output stream got closed in GeoServer face by a client
that decided to stop waiting, what you propose seems to hit a similar theme.
Let’s hear what others have to say
Cheers
Andrea
On Wed, Feb 8, 2017 at 3:00 PM, Daniel Baston <dbaston@anonymised.com> wrote:
Hello,
What people think about reducing the log level (from ERROR to INFO) for messages generated when a client requests a feature type that does not exist?
These requests do not indicate a problem with the server, and the client is correctly served a response indicating that the feature type does not exist.
Currently it’s possible for a single misguided client to flood the logs by requesting feature types that do not exist.
Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
sounds good to me, I’m always in favour of not yelling ERROR when it isn’t actually a problem
Ian
On 8 February 2017 at 14:08, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Daniel,
on my side I see it as a good thing, we already have some specialized logic to avoid
logging stack traces when the output stream got closed in GeoServer face by a client
that decided to stop waiting, what you propose seems to hit a similar theme.Let’s hear what others have to say
Cheers
Andrea
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
On Wed, Feb 8, 2017 at 3:00 PM, Daniel Baston <dbaston@anonymised.com> wrote:
Hello,
What people think about reducing the log level (from ERROR to INFO) for messages generated when a client requests a feature type that does not exist?
These requests do not indicate a problem with the server, and the client is correctly served a response indicating that the feature type does not exist.
Currently it’s possible for a single misguided client to flood the logs by requesting feature types that do not exist.
Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Ian Turton
Hi,
Not that I get a vote, but I also agree. Best not to present something as an issue when it isn’t.
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
sounds good to me, I’m always in favour of not yelling ERROR when it isn’t actually a problem
Ian
On 8 February 2017 at 14:08, Andrea Aime <andrea.aime@…1268…> wrote:
Hi Daniel,
on my side I see it as a good thing, we already have some specialized logic to avoid
logging stack traces when the output stream got closed in GeoServer face by a client
that decided to stop waiting, what you propose seems to hit a similar theme.
Let’s hear what others have to say
Cheers
Andrea
On Wed, Feb 8, 2017 at 3:00 PM, Daniel Baston <dbaston@…403…> wrote:
Hello,
What people think about reducing the log level (from ERROR to INFO) for messages generated when a client requests a feature type that does not exist?
These requests do not indicate a problem with the server, and the client is correctly served a response indicating that the feature type does not exist.
Currently it’s possible for a single misguided client to flood the logs by requesting feature types that do not exist.
Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ian Turton
+1 to reduce the logging level to INFO.
I see ERROR as being for "we did something wrong and should fix it", like HTTP 5xx Oops My Bad, whereas a client mistake or timeout is more like HTTP 4xx Not Our Problem, worthy only of INFO logging. Administrators can always adjust the logging level to investigate if needed.
Kind regards,
Ben.
On 09/02/17 03:08, Andrea Aime wrote:
Hi Daniel,
on my side I see it as a good thing, we already have some specialized logic
to avoid
logging stack traces when the output stream got closed in GeoServer face by
a client
that decided to stop waiting, what you propose seems to hit a similar theme.Let's hear what others have to say
Cheers
AndreaOn Wed, Feb 8, 2017 at 3:00 PM, Daniel Baston <dbaston@anonymised.com> wrote:
Hello,
What people think about reducing the log level (from ERROR to INFO) for
messages generated when a client requests a feature type that does not
exist?These requests do not indicate a problem with the server, and the client
is correctly served a response indicating that the feature type does not
exist.Currently it's possible for a single misguided client to flood the logs by
requesting feature types that do not exist.Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
I would be happy to handle this in a similar fashion; as you say it is correct client/server behaviour and not an error in the geoserver application.
On 8 February 2017 at 06:08, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Daniel,
on my side I see it as a good thing, we already have some specialized logic to avoid
logging stack traces when the output stream got closed in GeoServer face by a client
that decided to stop waiting, what you propose seems to hit a similar theme.Let’s hear what others have to say
Cheers
Andrea
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Jody Garnett
On Wed, Feb 8, 2017 at 3:00 PM, Daniel Baston <dbaston@anonymised.com> wrote:
Hello,
What people think about reducing the log level (from ERROR to INFO) for messages generated when a client requests a feature type that does not exist?
These requests do not indicate a problem with the server, and the client is correctly served a response indicating that the feature type does not exist.
Currently it’s possible for a single misguided client to flood the logs by requesting feature types that do not exist.
Ticket reference: https://osgeo-org.atlassian.net/browse/GEOS-7916
Dan
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.