Heavyweight java reporting
-
I'm working on a project where the previous developers obviously wanted to try out every new technology (whether it was needed or not), and also wherever possible to write their own versions of modules where one would usually use an off-the-shelf one. To implement scheduled running of reports, the process looked like:
1. Use quartz (an easy-to-use java scheduling library) to schedule your reports, BUT not directly -- use it to run some custom code EVERY 30 SECONDS that runs a whole lot of expensive database calls and re-implements quartz's cron parsing functionality to figure out when to run the reports
2. When your scheduled time comes up, call a service that sends a JMS message to a queue that is always in the same JVM
3. When you duly receive this message, figure out some parameters to run the report with and send ANOTHER JMS message (in the same style as step 2)
4. When you receive THIS message, invoke your custom-built workflow engine to run a workflow that has a single step
5. This step will actually run the report (using jasper), but it might need to email the resulting file to some people, so we will use (you guessed it)
6. YET ANOTHER JMS message
7. Which, when recieved, emails the resulting file to the desired people
I removed all the JMS queues and the workflow, and changed it to use quartz directly. I removed huge swathes of code, a whole lot of load of the server, and made it run quicker.
And I didn't even mention the custome class loader it used so it could load the report definitions off the database every time it needed to run the report ... *shudder*.
-
If Quartz does cron parsing, why not just use cron directly? It sounds like you refactored it pretty well, but is there a need to use something other than cron to run the reports?
-
@morbiuswilters said:
If Quartz does cron parsing, why not just use cron directly? It sounds like you refactored it pretty well, but is there a need to use something other than cron to run the reports?
Needs to be clustered, run on any type of server, and users can create new jobs through a web interface.
-
@tboss said:
@morbiuswilters said:
If Quartz does cron parsing, why not just use cron directly? It sounds like you refactored it pretty well, but is there a need to use something other than cron to run the reports?
Needs to be clustered, run on any type of server, and users can create new jobs through a web interface.
Makes sense. Given your post, I didn't think you'd make the mistake of reinventing the wheel. It would have been ironic and funny, though.
-
You made it much less "Enterprisy". However, if a job fails partway through after your fix, any output will be lost. Using the JMS messages, you're guaranteed delivery and can handle a minor thing like a computer freezing up...Restart and presto, your JMS message comes through again.
I'm not saying you need all that clap-trap. It is all about how reliable the app needs to be - e.g. if the world would end if one of the reports doesn't get generated...
-
@Auction_God said:
You made it much less "Enterprisy". However, if a job fails partway through after your fix, any output will be lost. Using the JMS messages, you're guaranteed delivery and can handle a minor thing like a computer freezing up...Restart and presto, your JMS message comes through again.
I'm not saying you need all that clap-trap. It is all about how reliable the app needs to be - e.g. if the world would end if one of the reports doesn't get generated...
In this case it was done this way because the previous developers had painted themselves into a corner and couldn't get the app to do anything at all without invoking the custom workflow engine and JMS messages.
