|any solution for limit runaway report queries ? [message #1049967]
||Fri, 26 April 2013 14:20
| nari noori
Registered: November 2012
Hi, i have embedded the BirtWebViewerExample in my spring web-application. I use birt 4.2.2 on a tomcat 6.|
i have 2 questions:
How to prevent users calling runaway report queries(sql queries that ask for millions of rows) in birt ?
My dream solution: would be that the user max can ask for 200.000 rows, and that mysql server just processes 200.000 rows,
approach 1: use input parameters to limit the result. example only let the user run reports with specific parameter values. As example preventing user to choose bigger data range parameter than 1 month or 2 months. But the weakness of this approach is that if i example have another query parameter let us say gender. You might be able to use larger date range when using other limiting query parameters.
approach 2: use limit 200.000; in sql-query....the query returns 200.000 rows, but does still run the whole query before limiting the result sent back.
approach 3: in birt report set dataset: max number of rows to fetch from data source to 200.000 rows. does the same thing as the approach above i gusss ?
What is the best solution ? is there a effective way to solve this ?
When i run a big query,that takes more than a minute, the birt report window just stops and shows me blank result after one minute (or just show the report result that was shown last time around). The sql query still keep running in background on the mysql server.
What i want to do is to delay the timeout that seems happen after a minute, any suggestions how to figure out the problem ?
in viewer.properties: viewer.session.timeout=0
in web.xml: BIRT_VIEWER_LOG_LEVEL set to FINEST (does not show any logging, maybe i have to change my log4j level to get logging ?)
in web.xml: session.timeout: 120 (minutes)
in DataSet in Birt Report: dataset:query timeout (in seconds): 300
[Updated on: Fri, 26 April 2013 14:30]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.03630 seconds