On a similar note, we have many reports that can take many minutes/hours to run. We initially offered the email option that Andreas mentioned, but we have since expanded that to full background reports. It was sold as a new feature that allows the user to "fire and forget" as many report requests as they like, but what it was really doing was letting us manage the report processing schedule. Since we now had control of the request, we could manage the threads better and program in things like queueing, quotas, memory and CPU checking, etc. The programming was actually pretty simple: report requests are inserted into a DB table and another background process is kicked off or scheduled to act on the requests. You can then tailor the background daemons to work however you wish. The bg processes either insert the reports into a table or write them to the file system and add a pointer to the table. The user can be notified when the report is done or they can simply check back when they have a spare moment.
-Lou Andreas L Delmelle <[EMAIL PROTECTED]> wrote on 01/16/2008 01:11:40 PM: > On Jan 16, 2008, at 18:27, Jay Bryant wrote: > > Hi > > >> I'm creating java servlet for making PDF file from xml and xslt > >> files. > >> It's possible making documents with 1000 pages or more ? How many > >> memory i > >> must have in my server to do this ? How long take generate this > >> file ? > > > > I've created a system that makes 2,000-page documents with FOP. > > Those documents had only one image (a logo on the cover) and > > consisted entirely of tables that described the contents of databases. > > > > I've also created a system that makes more complex documents that > > exceed 700 pages. Those are software user guides that include > > images, tables, lists (bulleted and numbered), very deep levels of > > nesting (think list within table within list), and all the other > > fun things that technical writers will do to a document when you > > tell them the system can handle anything. So far, it has handled > > everything they throw at it. > > > > The machines running those processes (they are at two different > > companies) have 1GB of RAM (and I configured Java to use all of > > it), and both processes run in just about two minutes. Both of > > those processes are triggered by users calling Ant build files > > (either from Eclipse or from the command line), but I'm sure they'd > > run on a server (though it might need 2GB RAM instead of 1GB). > > You'd just have to train your users to not hit the Back button for > > two or three minutes. > > If it helps, in a client/server context, one would obviously want to > fill those minutes with a combination of some fancy animation and > client-side scripting. > IIC, it should be perfectly possible to: > -> send an asynchronous request to a servlet (think AJAX) that > creates a temporary PDF on the server; the servlet's response would > be the URI for that file > -> while the request is processing on the server, display some > animation, offer the user some more info (documentation, FAQs). Take > care that any hyperlinks defined on the page actually redirect to a > frame on the page itself, so the user can keep himself busy without > leaving the page, or maybe even offer the option to have the end- > result (or its URL) delivered by mail if finished. Offer links to > additional servlets/applets/easter eggies for fun. ;-) > -> the onreadystatechange-handler for the asynchronous request then > needs to do little more than magically uncover an IFRAME and set its > src attribute to the URI that was returned > > The browser and its PDF plugin should handle the rest nicely, I think. > > > Cheers > > Andreas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
