You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "John Huss (JIRA)" <ji...@apache.org> on 2013/06/26 16:40:19 UTC

[jira] [Created] (CAY-1840) Conditionally log slow / long-running queries

John Huss created CAY-1840:
------------------------------

             Summary: Conditionally log slow / long-running queries
                 Key: CAY-1840
                 URL: https://issues.apache.org/jira/browse/CAY-1840
             Project: Cayenne
          Issue Type: Improvement
          Components: Core Library
    Affects Versions: 3.2M1
            Reporter: John Huss
            Assignee: John Huss
            Priority: Minor
         Attachments: 0001-Add-conditional-logging-for-queries-that-take-longer.patch

I wanted to add logging slow / long-running queries without having to log every single query, so I made a patch to do it.  But there are a lot of implementation questions and some general design questions about the jdbcLogger.

1) I added a property to control the logging threshold - seems like these should go in Constants, but there was already a property defined in JdbcAdapter where I was working, so I just put it there.  Also, I'm not sure what the property naming conventions are exactly.  I called it "cayenne.server.query_execution_time_logging_threshold"

2) For the JdbcLogger, currently all the messages are at the INFO level.  I can't add this new logging with that level because then you wouldn't be able to see just the long-running queries, you would still see all or none.  So I added generic "warn" method that uses the WARN level.  But I wonder if a more semantic method would be better, like "logLongQuery" or something.  Also, I wonder if it would be better to push the existing SQL logging down to the debug level and leave the connection opening at the INFO level so you could just see those logs (which is something I have wanted).

3) I am logging only the SQL string and not the parameters because there wasn't any easy way to access the params from the logger.  Ideally the params would be logged also.

4) In Project Wonder some functionality like this exists, but it allows you to pair log levels with query running times, so you could log at the WARN level for queries longer than one second and log at the ERROR level for queries longer than five seconds.  I don't think this is very important as it complicates the property API, but I thought I would throw out the idea.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Created] (CAY-1840) Conditionally log slow / long-running queries

Posted by John Huss <jo...@gmail.com>.
On Wed, Jun 26, 2013 at 10:35 AM, Mike Kienenberger <mk...@gmail.com>wrote:

> On Wed, Jun 26, 2013 at 10:40 AM, John Huss (JIRA) <ji...@apache.org>
> wrote:
> >              Summary: Conditionally log slow / long-running queries
> >                  URL: https://issues.apache.org/jira/browse/CAY-1840
> >
> > 2) For the JdbcLogger, currently all the messages are at the INFO level.
>  I can't add this new logging with that level because then you wouldn't be
> able to see just the long-running queries, you would still see all or none.
>  So I added generic "warn" method that uses the WARN level.  But I wonder
> if a more semantic method would be better, like "logLongQuery" or
> something.  Also, I wonder if it would be better to push the existing SQL
> logging down to the debug level and leave the connection opening at the
> INFO level so you could just see those logs (which is something I have
> wanted).
>
> +1 for moving sql logging down to debug level and leaving connection
> opening at INFO.
>
> > 4) In Project Wonder some functionality like this exists, but it allows
> you to pair log levels with query running times, so you could log at the
> WARN level for queries longer than one second and log at the ERROR level
> for queries longer than five seconds.  I don't think this is very important
> as it complicates the property API, but I thought I would throw out the
> idea.
>
> +1 for using a different logger for slow queries, and maybe adjusting
> what is logged by default by logger level
>
>
> > 3) I am logging only the SQL string and not the parameters because there
> wasn't any easy way to access the params from the logger.  Ideally the
> params would be logged also.
>
> Don't we already log parameters with the existing logging code?
>

Yes, they are logged inside the SelectTranslator before the query is run.
 However, this new logging would happen AFTER the query has run and
currently there isn't public API to grab the query params from outside
SelectTranslator where this happens.

Re: [jira] [Created] (CAY-1840) Conditionally log slow / long-running queries

Posted by Mike Kienenberger <mk...@gmail.com>.
On Wed, Jun 26, 2013 at 10:40 AM, John Huss (JIRA) <ji...@apache.org> wrote:
>              Summary: Conditionally log slow / long-running queries
>                  URL: https://issues.apache.org/jira/browse/CAY-1840
>
> 2) For the JdbcLogger, currently all the messages are at the INFO level.  I can't add this new logging with that level because then you wouldn't be able to see just the long-running queries, you would still see all or none.  So I added generic "warn" method that uses the WARN level.  But I wonder if a more semantic method would be better, like "logLongQuery" or something.  Also, I wonder if it would be better to push the existing SQL logging down to the debug level and leave the connection opening at the INFO level so you could just see those logs (which is something I have wanted).

+1 for moving sql logging down to debug level and leaving connection
opening at INFO.

> 4) In Project Wonder some functionality like this exists, but it allows you to pair log levels with query running times, so you could log at the WARN level for queries longer than one second and log at the ERROR level for queries longer than five seconds.  I don't think this is very important as it complicates the property API, but I thought I would throw out the idea.

+1 for using a different logger for slow queries, and maybe adjusting
what is logged by default by logger level


> 3) I am logging only the SQL string and not the parameters because there wasn't any easy way to access the params from the logger.  Ideally the params would be logged also.

Don't we already log parameters with the existing logging code?