Loading Profile...
To ignore "rogue reports risks" or not?
I am curious, do you plan to implement any measures that would prevent unsuspecting (naive) users from "hurting" themselves by creating and running "rogue" reports; or measures that would lessen their potential negative impacts?
Here is an example of such a rogue report: open the Daily Accounting Summary (Browser Cruncher) report and view it as an Area Chart (a pie chart "works" even better ;). On my machine, this action locked up the browser for long minutes (FF3, XP, Core2Duo, 3GB RAM). I knew it was my mistake to run such a silly report a minute after I had started it; but once started, it could not be cancelled or interrupted except for killing the whole browser. Yikes!
Or, is this a risk that you can and plan to live with? This report's twin brother with swapped headers works just fine and might have some value for somebody (watching trends etc.). The difference in inputs that makes the report fly or fail is dangerously small, IMO, even for an educated user. OTOH, perhaps this is just a trivial scability/performance bug and my worries are totally pointless. ;)
Here is an example of such a rogue report: open the Daily Accounting Summary (Browser Cruncher) report and view it as an Area Chart (a pie chart "works" even better ;). On my machine, this action locked up the browser for long minutes (FF3, XP, Core2Duo, 3GB RAM). I knew it was my mistake to run such a silly report a minute after I had started it; but once started, it could not be cancelled or interrupted except for killing the whole browser. Yikes!
Or, is this a risk that you can and plan to live with? This report's twin brother with swapped headers works just fine and might have some value for somebody (watching trends etc.). The difference in inputs that makes the report fly or fail is dangerously small, IMO, even for an educated user. OTOH, perhaps this is just a trivial scability/performance bug and my worries are totally pointless. ;)
I’m curious.
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Very good point. We have implemented certain limits in terms of report computing duration, size of the resulting table, and size of some underlying caching structures. These limits are very generous and thanks to our caching mechanism we do not experience any "rogue" report issues on small data sets under roughly 20M records (there are only 2.5M records in the biggest Foodz.com demo table). The limits start to be interesting in larger data sets.
The report canceling mechanism is already implemented on the back-end. We are currently wrapping it in it's REST API and working on the UI. You should see it soon in our platform.
The problem that you are experiencing is caused by some performance issue in our charting library (OEM for now). For some reasons it does not scale beyond several dozens of chart series. According our research the issue is caused by the label drawing mechanism. The charting runs as JavaScript component in your browser and it locks it up during it's crunching. We are aware of this issue and it is very high on our list.
Thanks for your suggestions, lazy bastard! ;-)
I’m thankful
-
Inappropriate?FYI - clicking on the link provided by Petr gives me "Unexpected error occurred" message an the "clock" seems to be spinning forever. -
Inappropriate?The "Unexpected error" currently does not cancel the indicator. We will fix this.
EMPLOYEE
