cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] [Updated] (CAY-1840) Conditionally log slow / long-running queries
Date Mon, 22 Jul 2013 13:27:25 GMT
I will, thanks! 

On Jul 22, 2013, at 4:23 PM, John Huss <johnthuss@gmail.com> wrote:

> Andrus, can you take a look at the updated patch?  Thanks.
> 
> On Monday, July 8, 2013, John Huss (JIRA) wrote:
> 
>> 
>>     [
>> https://issues.apache.org/jira/browse/CAY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>> 
>> John Huss updated CAY-1840:
>> ---------------------------
>> 
>>    Attachment:
>> 0001-CAY-1840-Conditionally-log-slow-long-running-queries.patch
>> 
>> Ok, updated patch for review.
>> 
>>> 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-CAY-1840-Conditionally-log-slow-long-running-queries.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
>> 


Mime
View raw message